WCF 和领域模型 - 不需要贫血吗？
以下是反对 Martin Fowler 提出的 贫血域模型 的论点（请阅读 链接）。
现在，根据此描述，人们会期望业务对象不仅具有 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 服务调用正确公开（课程仅通过只读属性公开）。这意味着我需要有一个返回列表的课程 getter 和 setter，
所以贫血域模型不适合 WCF，并且仅当客户端可以实际使用代码时才适合适当的域模型（Asp.net 在服务器端或在服务器端时）使用 Silverlight 等时的客户端业务实体）。
Here is the argument against an Anemic Domain Model as presented by Martin Fowler (read link).
Now based on this description, one would expect the business object to not just have getters and setters, but also behavior, such as what I show below.
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;
}
}
But an object like the Student as described above cannot be properly exposed via a WCF service call (Courses is exposed only via a readonly property). Which would mean that I need to have a Courses getter and setter which returns a List
So isnt the Anemic domain model appropriate for WCF and a proper domain model appropriate only when the client can actually use the code (Asp.net when server side or in the client side business entities when using Silverlight, etc).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在这种情况下，您所说的贫血数据模型，我称之为数据传输对象。
领域模型捕获行为和驱动行为的数据。通常通过远程端点按原样公开域模型通常会遭受过多的耦合并遇到实际问题。
通常，数据传输对象 (DTO) (http://martinfowler.com/eaaCatalog/dataTransferObject.html) 是解决设计紧张的好方法。
最终将有代码遍历您的域模型属性并将数据复制到适当的 DTO 以返回到 WCF 服务的调用者。
In this context, what you call Anemic Data Model, I'd call Data Transfer Object.
Domain model captures behavior and the data that drives the behavior. Often exposing a domain model as-is over a remote endpoint often suffers from too much coupling and runs into practical problems.
Often Data Transfer Objects (DTO) (http://martinfowler.com/eaaCatalog/dataTransferObject.html) is a good way of solving that design tension.
There will end up being code that walks your domain model properties and copies the data over to the appropriate DTO for return to the caller of your WCF service.