我正在看着
differences between POCO and DTO(似乎POCO是dto的行为(方法？))，并由Martin Fowler在07年由贫血领域模型出现。
通过缺乏理解，我想我已经创造出了这些贫血域模型之一。
在我的一个应用程序中，我的业务域实体在’dto’dll中定义。他们有很多属性与吸气者和设置者，没有太多的其他。我的业务逻辑代码(填充，计算)在另一个“bll”DLL中，我的数据访问代码是一个“dal”dll。 “最佳实践”我想。
所以通常我会这样创建一个dto：
dto.BusinessObject bo = new dto.BusinessObject(...)
并将其传递给bll层，如下所示：
bll.BusinessObject.Populate(bo);
这又反过来执行一些逻辑，并将其传递给dal层，如下所示：
dal.BusinessObject.Populate(bo);
从我的理解，要使我的dto进入POCO，我需要使业务逻辑和行为(方法)成为对象的一部分。所以代替上面的代码更像是：
poco.BusinessObject bo = new poco.BusinessObject(...) bo.Populate();
即。我正在调用对象上的方法，而不是将对象传递给该方法。
我的问题是 – 我该如何做到这一点，仍然保留“最佳实践”分层关注(单独的dll等)。不调用对象上的方法意味着方法必须在对象中定义？
请帮助我的困惑。
通常，您不想将持久性引入您的域对象，因为它不是该业务模型的一部分(飞机不构建自身，它将乘客/货物从一个位置飞到另一个位置)。您应该使用
repository pattern，
ORM framework或其他数据访问模式来管理对象状态的持久存储和恢复。
贫血域模型的出现在你做这样的事情时：
IAirplaneservice service = ...; Airplane plane = ...; service.FlyAirplanetoAirport(plane,"IAD");
在这种情况下，飞机的状态(无论是飞行，在哪里，起飞时间/机场，到达时间/机场是什么，什么是飞行计划等)的管理被委托给飞机外部的东西。 Airplaneservice实例。
实现这一点的POCO方式是以这种方式设计你的界面：
Airplane plane = ...;
plane.FlyToAirport("IAD");
这是更可发现的，因为开发者知道在哪里寻找飞机飞行(只是告诉飞机去做)。它还允许您确保状态仅在内部进行管理。然后，您可以将当前位置的内容像只读方式一样，并确保它只在一个地方更改。随着贫血域对象，由于状态设置为外部，发现状态改变的地方变得越来越困难，因为您的域的规模越来越大。