如何解决POCO类应该包含方法吗?如果是,它们与域对象有何不同?
好吧,所以我一直试图绕着domain driven development (DDD).
我知道POCO
类应该很简单,并且与实体框架没有任何联系。这些类将在需要任何数据库操作时映射到实体。
我还知道,在DDD
中,您拥有包含所有业务逻辑的类。
我的问题是,如果我开始将逻辑和方法放入我的POCO
类中,它们将不再保持简单,但是如果我开始分别创建和使用域类,则需要首先映射我的域反对POCO
,然后POCO
反对实体对象,反之亦然,这变得越来越忙。
所以我应该这样:Entities <--> POCO (Simple class) <--> Domain Object (All business logic)
还是应该摆脱POCO类,而只使用域类,因为无论如何我已经完成了包括BL和EF实体之间的层分离的工作。
谢谢。
解决方法
根据定义,POCO内部没有任何逻辑。它们主要是一个holder类,仅由各种字段和属性组成。一旦开始向其中添加逻辑,就可以朝着域驱动设计的方向前进。
许多开发人员,例如马丁·福勒(Martin Fowler)都正确地辩称,POCO的广泛使用导致产生Anemic Domain Model,Wikipedia定义为:“ ...使用领域对象包含其中的软件领域模型很少或没有业务逻辑”。我认为,如果您不采取主动措施来减轻EF的贫血模型,那绝对是一个真正的风险。
这并不是说每个为实体使用POCO的系统都注定要产生ADM。实际上,杰森·泰勒(Jason Taylor)拥有amazing talk的清洁架构知识,他的Northwind Traders demo展示了一些不错的方法,可以在不牺牲太多清晰度的情况下细分应用程序。
现代实体框架核心非常适合两种设计范例(POCO和DDD),因此实际上没有“正确”的答案。在大多数非平凡的用例中,我个人都采用了混合方法。我的实体模型包含实体的硬性和快速性,通用领域规则;不要与域逻辑相混淆。我的域层包含大多数相关的域逻辑,或者说各种实体之间如何交互。我的应用程序层将所有内容组合在一起,并且包含负责使程序运行的实际逻辑。
我仍然有POCO,但是它们主要用于与客户端之间传输数据。我将它们与AutoMapper和FluentValidation结合使用以简化样板代码,但是它们并不是必需的。
因此,关于POCO问题,答案是:“取决于情况”。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。