以下是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服务调用正确公开(课程仅通过readonly属性公开)。这意味着我需要一个Courses getter和setter来返回一个List
因此,适用于WCF的Anemic域模型以及仅当客户端可以实际使用代码时才适用的适当域模型(Asp.net在服务器端或在客户端业务实体中使用Silverlight时等)。
答案 0 :(得分:1)
因此,不适合WCF的贫血域模型
在这种情况下,你称之为贫血数据模型,我称之为数据传输对象。
域模型捕获行为和驱动行为的数据。经常在远程端点上暴露域模型经常会遇到过多的耦合并遇到实际问题。
数据传输对象(DTO)(http://martinfowler.com/eaaCatalog/dataTransferObject.html)通常是解决设计紧张的好方法。
最终会有代码遍历您的域模型属性并将数据复制到相应的DTO以返回到WCF服务的调用者。