2

我们的新项目刚刚开始，我们遇到了与其架构相关的问题。

我们有一个 3 层架构：

  1. 网页界面
  2. 商业
  3. 资料库

每个层都只引用它下面的层。通信是通过我们所说的entities和business objects(BO) 完成的，如下所示：

DataRepositories <--entities--> Business <--BO--> WebUI

<--X-->表示使用 X 类型的对象进行通信。

因此，我们有例如UserEntity实体和UserBO。另一种类型是再次具有TicketEntity和的票Ticket。

目前，我们在层中有一些不同的垂直切片，例如AccountsDataRepositories、Business 和 WebUI 中的用户，这些切片定义明确并且不与其他切片（如Tickets.

现在的问题是一张票有一个买家是用户，我们不知道在我们的架构中应该在哪里连接票和用户。业务组件应该在它们之间进行交互，还是数据层应该将用户映射到工单？

更具体地说，我们有一种方法用于创建驻留在 Business 中并从 WebUI 调用的工单。它将票证和“用户”的详细信息作为参数，我们还不知道它应该是用户类型的对象还是只是用户名/ID。如果我们传递一个用户对象，那么演示文稿应该在调用 CreateTicket 之前获取用户。但是，如果 webui 传递了 id，那么业务层应该解析用户对象，这需要在门票（业务）中添加对用户业务组件的引用。

4

1 回答 1

2

就个人而言，我讨厌这样的并行层次结构。您已经创建了您所称的实体，它应该有一些与它们相关联的行为，以及应该是不可变且没有任何行为的业务对象的并行层次结构。

我会放弃业务对象。我怀疑除了不变性和其他人的“架构纯度”概念之外，它们没有提供任何可以引用的价值。

我也不喜欢实体和存储库之间的箭头方向。我会让存储库知道实体，但不是相反。为什么实体应该知道或关心它是否被持久化？业务逻辑和行为应该保持不变。

我会让视图层与服务交互。这些与 UI 无关，但它们包含您完成用例的所有业务逻辑。如果你扔掉你的 UI - 你每隔几年就会扔掉 - 只要业务问题存在，你的服务就会一直存在。

数据层应该对自己的引用完整性负责。如果一张票需要加入来找到它的用户，那么你必须把它放在数据层中。当持久层查询用户时，它还将获取属于该用户的票证并返回对象中的一对五关系。一个用户将有一个列表或一组票实例。所有这些都应该在服务层完成。该服务将协调实现用例所需的持久性、业务对象和其他服务。

于 2011-06-26T17:59:02.980 回答