为模型拥有一个简单的POCO的参数

Question

我是一名程序员，我认为我在OO方面受过良好的教育。我相信POCO (C#)和一个只有get/set方法来封装数据的模型。3层域模型。

我正在寻找支持具有简单域模型和服务层中所有业务逻辑的值的文档，以及用于数据访问的DAL。

马丁·福勒：

http://martinfowler.com/eaaCatalog/domainModel.html

http://martinfowler.com/bliki/AnemicDomainModel.html

表示(贫血)域模型没有值，要使其具有值，它必须处理总线逻辑或/和数据CRUD操作。我需要一些能为马丁·福勒辩护的好书。(这不是解雇马丁·福勒的问题，我尊重他的工作。我正在寻找一个更好的理解我们正在做什么，为什么？)

Answer 1

你可以从..。福勒自己。

PoEAA，第110页，事务脚本：

不管一个对象有多么偏执，也不要排除事务脚本。这里有很多简单的问题，一个简单的解决方案会让你更快地启动和运行。

事务脚本并不完全是您所描述的服务类型(它可能不使用域对象，甚至是贫血对象)，但它非常接近。

另外，请注意，POCO的概念并没有假设一个对象的沉闷或贫血。您可以使用包含行为的富域POCOs。POCO/POJO描述了一个简单的本机对象，而不是带有注释或属性修饰的对象，或者是从框架继承特殊类的对象，通常是为了持久化目的。

Answer 2

看看DCI体系结构，它将数据从行为中分离出来，试图通过分割引起不同变化率的部分来控制软件的发展。它还使用角色或特性的概念来实现将数据和行为重新组合在一起所需的功能。

有一本书涉及更广泛的体系结构主题，强调DCI:敏捷软件开发的精益体系结构。

Answer 3

引用Fowler，贫血域模型

本质上，贫血领域模型的问题在于，它们会导致域模型的所有成本，而不会产生任何好处。

成本包括将对象映射到数据库，以及设计(贫血)域模型所付出的努力。如果你已经决定你不需要DDD的好处和贫血相关的成本是可以接受的，你已经有了一个相反的论点。

但是，确保您的贫血模型+服务+ DAL (+UI?)比活动记录应用程序( Rails )便宜吗？圣杯？)加上一些事务脚本。

当我们想要简化一个复杂的问题，而不是将一个简单的问题“复杂化”时，通常应用领域驱动的设计。再次引用福勒

域模型并不总是最好的工具。

分析您的需求，选择合适的架构并交付您的应用程序。