Value Object是一个糟糕的模式吗？

Question

使用VO(POCO)是一种糟糕的设计模式吗？有人说对象的所有域逻辑都需要在该对象中.

例如:ProductVO:Id,Name,Description

ProductBO:SearchById(int id),Insert(ProductVO newProduct),Update(ProductVO updatedProduct,SearchByKeyword(string word)......

Answer 1

所有域逻辑都应该在域对象中,在域对象中...但是有一个强有力的论据,即技术问题,如如何将对象保存到数据库,或记录对象活动,都不是域行为,它们是基础架构或应用程序问题,不应该在域对象中......

检查域驱动设计,在此方法中,建议您将持久性逻辑的域相关方面(如持久化/提取对象)分离为一个名为存储库的单独类型(也在域层中)...但即使在这里,如何与数据库或其他持久性存储技术进行通信的技术方面更容易分离为基础结构服务.

一种看待这种情况的方法是将服务划分为三组,

Infrsastructure服务.那些与一般技术方面有关的内容(如通用数据库访问,缓存,日志记录,配置,消息传递等)
应用服务.这涉及与业务领域无关的技术或应用程序设计方面(UI中的MVC模式,屏幕导航,域实体初始化方法等).
域名服务.与业务模型明确相关的服务.(例如,为特定航班上的航空公司座位创建预订,具有特定的膳食请求和座位分配,以及对指定信用卡的适当交易借记......)

最后一种类型的"服务"应该在域层,前两个, - 不是......

Answer 2

使用VO(POCO)是一种糟糕的设计模式吗？有人说对象的所有域逻辑都需要在该对象中.

我认为这里存在很多混淆,因为"价值对象" 有两个几乎完全矛盾的定义.

POCO/POJO也不是一个合适的表达式,因为它并不意味着缺少逻辑,只是不需要特定的超类,接口或字节码增强.

至于你的问题:在没有逻辑的类中拥有一个领域模型,除了看到其他人这样做,并且有一个名字,这确实是非常糟糕的设计 - 它是一种被称为贫血领域模型的反模式.不幸的是,有许多设计糟糕的框架(现在通常被抛弃)需要并促进这种"模式".

它忽略了面向对象的基本思想:用操作它的逻辑封装数据,并且它通常导致冗长,不灵活和脆弱的代码,因为外部逻辑现在需要被显式调用并传递模型,它变得更加困难.确保无法传递无效数据,并且有关域模型结构的知识广泛传播.

话虽如此,"对象的所有域逻辑需要在该对象中共存"绝对不是真的 - 有时候有充分的理由提取一些域逻辑并将其保存在单独的类中:

但通常,关于对象的域逻辑应该是该对象的一部分,除非您有特定的理由将其放在其他位置.