对模型进行简单POCO的论点

Question

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

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

Martin Fowler：

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

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

表示（贫血）域模型没有价值，并且要有价值，它必须处理buslogic或/和数据CRUD操作。 我需要一些好书，对马丁福勒有一些反驳。 （这不是解雇Martin Fowler的情况，我尊重这项工作。我正在寻找一个更好的理解我们正在做什么以及为什么？）

Answer 1

你可以从......福勒本人那里找到反驳。

PoEAA，p。 110，交易脚本：

  

然而，你变成了很多对象，不排除交易   脚本。那里有很多简单的问题，而且很简单   解决方案可以让您更快地启动和运行。

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

另外，请注意POCO的概念并不假设任何关于物体的愚蠢或贫血。您可以拥有包含行为的富域POCO。 POCO / POJO描述了一个简单的本机对象，而不是用注释或属性修饰的对象，或者从框架继承特殊类，通常用于持久性目的。

Answer 2

看一下DCI architecture，它将数据与行为分开，试图通过分割导致彼此不同变化率的部分来控制软件的演变。它还使用角色或特征的概念来实现将数据和行为重新组合在一起的所需功能。

有一本书解决了更广泛的体系结构主题，强调DCI：James Coplien的敏捷软件开发精益架构。

Answer 3

引用福勒，anemic domain model：

  

本质上是问题所在   贫血领域模型是他们承担的所有成本   域模型，没有任何好处。

成本包括将对象映射到数据库以及您为设计（贫血）域模型所付出的努力。如果您已经决定不需要DDD的好处并且可以接受贫血模型相关的费用，那么您已经得到了反驳。

但是，请确保您的贫血模型+服务+ DAL（+ UI？）比active record应用程序（Ruby on Rails？Grails？）便宜一些transaction scripts。

当我们想要简化复杂问题时，通常应用域驱动设计，而不是“复杂化”＃34;一个简单的。再次引用Fowler：

  

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

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