4

我正在尝试实践领域驱动设计，代码的基本结构包括以下对象：

Action->Facade->
Service
Model
Repository

您认为应该将 CRUD 方法放在 Model 中的什么位置，如下所示：

order.save(new order())

或者像下面这样放在门面：

addOrderFacade.save(new order())
4

3 回答 3

7

“保存”或“删除”方法属于存储库。通常保存由服务或命令处理程序调用（如果您使用基于命令的方法来更新域）。从 CRUD 中保存句柄 CU，D 有自己的方法，R 部分是有趣的部分。

当 R 表示“GetEntity”以便更新它时，它可以是域存储库的一部分（有超过 1 个存储库），在与保存相同的位置处理。

但是，如果您想阅读以显示，基本上只是将结果返回给用户的查询，则应使用专用于查询的不同存储库以及简化的只读模型。可以从控制器甚至 UI 调用此 repo。

于 2012-06-14T06:35:46.813 回答
2

我建议不要将它们放在域类中，因为，

您的域类包可以在其他应用程序的某个地方重用，您的 DAO 层会有所不同，因此最好在 DAO 模型上创建另一个层

于 2012-06-14T04:35:13.913 回答
1

惯例是将 CRUD 方法放在存储库或服务层而不是模型中。事实上，当使用 Spring 或 Hibernate 等框架时，您会被诱使使用这种方法。仅出于这个原因，它通常更容易：

  • 其他开发者期待它
  • 框架支持它
  • 教程和示例假设它

然而，从设计的角度来看，有充分的理由反对这种方法。它导致了一个贫乏的领域模型，换句话说，对象只有状态而没有行为（结构），公平地说，它不是非常面向对象的。需要通过视图、控制器、服务和存储库层传递大量数据，并且需要大量“开销”代码来将状态和行为结合在一起。对规范模型层缺乏关注也可能导致团队之间的模型不匹配、碎片化。

试图避免这种设计陷阱的方法通常被称为领域驱动设计，由 Eric Evans 定义。请注意，在 DDD 中，仍然有服务和存储库的位置，来自 Wikipedia 页面：

  • 服务：当操作在概念上不属于任何对象时。遵循问题的自然轮廓，您可以在服务中实现这些操作。服务概念在 GRASP 中称为“Pure Fabrication”。
  • Repository：检索域对象的方法应委托给专门的 Repository 对象，以便可以轻松地互换替代存储实现。
  • 工厂：用于创建领域对象的方法应该委托给专门的工厂对象，以便可以轻松地互换替代实现。

如果您有兴趣，请查看支持 DDD的软件工具和（就在下方）DDD 示例应用程序。

于 2012-06-14T07:21:04.590 回答