“事务脚本”、“表模块”和“域模型”，以便在业务层制作业务组件？

Question

我正在研究“事务脚本”、“表模块”和“域模型”，但对我来说似乎有点复杂。

你能给我一个比较这三种方法的例子吗？

谢谢

Answer 1

我有同样的问题，我想到了以下示例：

想象一个具有以下用例的在线商店应用程序：

1. 用户购买产品

   • 浏览产品
   • 将一件或多件放入购物车
   • 结帐（输入付款和运输信息等）

2. 用户编辑他们的个人资料

   • 更改密码
   • 输入/更新付款信息

使用事务脚本，我们将为每个用例创建一个类，每个事务/请求一个函数！

class BuyProduct {
  List getProducts(string filter) { /* some database query */ }
  void putInCart(int productId, int amount) { ... }
  void checkout(...) {...}
}
class EditProfile {
  void changePassword(string newpwHash) { ... }
  void updatePaymentInfo(...) {...}
}

当没有太多逻辑要实现并且我们只需要一组分组的数据库事务时，这是有道理的！（以及您不需要经常重用代码的地方）

使用领域模型，我们将在领域对象上映射现实。我们将有 User、Product、ShoppingCart、ProductFilter、PaymentInformation 等类，这些类具有执行与类相关的任务的函数。

例如：

class User {
  string getPaymentInfo() {...}
  void updatePaymentInfo() {...}
}

例如，这些函数可以自己执行数据库查询，也可以将它们委托给持久层。

这种方法对于具有大量逻辑和需要经常重用代码的情况的非常复杂的应用程序很有意义。

带表模块我们可以将数据库表映射到对象。

例如，在这种情况下，可能有产品表、用户表和订单表（跟踪已完成的订单及其状态）的类。不仅表，而且定制的数据库视图和事务/请求都可以映射到类/对象。

一个简单的例子：

class ProductTable {
  List getProducts(string filter)
  void updateAmountAvailable(int productId, int newAmount) {...} // call after someone bought a product to update it's availability
  ...
}

这对于在数据库上有大量工作/逻辑的小型应用程序很有意义。但它不能很好地扩展复杂性。

总体：对于小型应用程序，请使用 tansaction 脚本。域模型最适合非常复杂的应用程序。表模块（据我所知）相当不常见，使用 ORM 可能更好。

Answer 2

我希望您参考 Fowler 的同一本书 - http://martinfowler.com/eaaCatalog/

• 事务脚本主要是程序性的。因此，您将拥有一个函数/脚本来顺序执行步骤（每个步骤都会产生一些变化）
• 领域模型是面向对象的，需要最多的工作 - 您需要提出一种共享语言和一个反映领域中感兴趣的对象的对象模型。
• 表模块对我来说是新的。它看起来也很面向对象，除了它更重视数据库模式这一事实之外。表模块对象看起来就像特定数据库表的 GateKeeper。主要对数据库表中的数据进行关联和操作的所有逻辑都位于相应的 TableModuleObject 中。引用自链接

与域模型 (116) 的主要区别在于，如果您有许多订单，则域模型 (116) 每个订单将有一个订单对象，而表模块将有一个对象来处理所有订单。