【发布时间】:2011-03-23 21:27:51
【问题描述】:
这是 Martin Fowler 提出的反对 Anemic Domain Model 的论点(阅读 link)。
现在基于此描述,人们会期望业务对象不仅具有 getter 和 setter,而且还具有行为,例如我在下面显示的内容。
public class Student
{
private List<Course>_courses = new List<Course>();
public string Name{get; set;}
public ReadOnlyCollection<Course> Courses {
get{ return _courses.AsReadOnly();}
}
public void Add(Course course)
{
if (course != null && _courses.Count <= 3)
{
_courses.Add(course);
}
}
public bool Remove(Course course)
{
bool removed = false;
if (course != null && _courses.Count <= 3)
{
removed = _courses.Remove(course);
}
return removed;
}
}
但是像上述 Student 这样的对象不能通过 WCF 服务调用正确公开(课程仅通过只读属性公开)。这意味着我需要有一个返回列表的 Courses 获取器和设置器
因此,Anemic 域模型不适合 WCF,而适当的域模型仅适用于客户端实际可以使用代码(Asp.net 用于服务器端或客户端业务实体使用 Silverlight 等)。
【问题讨论】:
-
你不应该通过网络传递域对象(无论是否贫血)。将它们投射到 DTO 并通过它们。请记住,只有当您尝试做一个真正的领域模型时,贫血领域模型才是一种反模式。
-
这就是为什么像 WCF RIA 服务这样的框架如此可怕的原因。他们实施了一种通过网络端到端推送“域对象”(Microsoft 的错误术语)的模型。它在理想情况下从不工作,但它很容易卖给愚蠢的 bean 计数器,他们看到我们只在服务器上编写一次糟糕的验证逻辑并认为它是灵丹妙药。
标签: design-patterns oop