非贫血代码将导致消失的控件类
问题描述：
我花了很多时间阅读最近有关良好的面向对象设计实践，包括像（避免）AnemicDomainModel主题。其含义是，班级应该是能够管理自己的状态和行为的活的，聪明的事物。我也是Adam Bein的粉丝，在观看他提倡ECB设计模式的视频后，我总结出这将非常适合我写的应用程序。我面临的问题是，如果我设计我的实体bean的方式具有丰富的行为，那么很难弄清楚控件类应该扮演什么角色，因为大部分函数都在实体类中。业务逻辑变得简单到足以考虑放置在边界“服务”类中，但这违反了基本原理ECB，实体不应该与边界通信。我被告知，我“过度思考”这一点，而经理和控制者毕竟不是什么坏事。 是否有人成功地将ECB与非贫血代码结合在一起，如果有的话，您可以提供什么建议？非贫血代码将导致消失的控件类
答
我会尝试从问题解决的几个点和后续评论，不一定是为了。
- “ECB设计为分离界面，业务逻辑和数据...”
相反，欧洲央行旨在结合业务逻辑和数据（避免贫血域模型），而是将业务逻辑与协作和流程逻辑分开。从关于ECB的链接wiki文章：
行为和业务规则......应该分配给实体;控制元素只负责场景的流程。
- “ECB和Demeter的规律是矛盾的，”
- “它变得很难找出哪一部分控件类应该发挥”
调用服务来检索数据并不违反的LoD。检索到的数据本身不是服务实现的一部分（仅仅是检索机制），所以客户端不会通过利用其接口获得不适当的服务知识。
至于你提到，欧洲央行的基本原则是分离的实体从边界开始，所以与边界相关的任何业务逻辑都必须由控制器进行协调。在一个简单的应用程序中，实体和边界之间的交互可能非常简单，因为边界很少。随着应用程序的增长，边界的数量也在不断增加，其交互的复杂性也在增加。
如果欧洲央行正在引领你走向一个“贫血控制模型”我不认为这是一件坏事，只要你的实体和边界保持分离，并凝聚力与他们预期的作用。
不熟悉ECB但基地你提供给它看起来像我平时用的办法的链接。你的“服务”似乎处于“控制”层，代之以用例，而不知道它是如何提供给外部世界的。你应该有另一层“边界”旨在面对外部世界（并委托你的服务工作） –
为了引出质量响应，需要一个更尖锐的问题。任何答案都可以解决这个问题，“你能提供什么建议？” – jaco0646
如果实体使用JPA持久性，那么EntityManager是控件，实体可以通过em由边界代码访问。 如果实体是独立的或简单的POJO，边界可以引用它的唯一方式（根据ECB的规则）是通过添加不必要的控制类来打破Demeter的法则。因此，欧洲央行和德米特法律是矛盾的，欧洲央行的目的是分离界面，业务逻辑和数据，所以你自然会通过其他人得到你需要的东西。 我不敢相信我是正确的，能指出我的逻辑错误吗？ – mikee