2

我一直在尝试理解这种新型架构，其名称可以是 Onion 架构、Clean 架构、端口和适配器等。

如果我采用端口和适配器的抽象，当我为特定端口调整我的应用程序时，我可以从我的应用程序内部给端口一个实体吗？还是我总是应该调整实体以适应端口？

例子：

假设我有一个客户实体。我有一个使用我的应用程序的 UI。我的 UI 通过适配器调用 getCustomerById(123)。反过来，我的适配器将调用我的应用程序，使用注入的存储库有效地检索客户，并将对其执行某种格式化和日志记录，一旦客户准备好，它就会返回到我的 UI。我的问题是，我的 Customer 对象按原样返回到我的 UI。这意味着我的 UI 引用了我的 Core 项目中的 Customer 类。然后我的 UI 继续使用该客户对象来做事，可能会更改它的名称等，并最终再次调用适配器来更新客户（客户）。

这可以吗？我的 UI 可以在我的应用程序核心内部使用 Customer 类吗？或者我应该改为让我的客户适应一个新的客户对象，比如 UICustomer 并让我的 UI 使用它，在适配器级别在客户和 UICustomer 之间来回映射？

4

2 回答 2

1

我也开始学习/实现洋葱架构。据我所知，您的原始方法（UI 中的客户实体）是一种可接受的做法。在此处查看洋葱架构的图形线性表示：

http://jeffreypalermo.com/blog/the-onion-architecture-part-3/

您可以看到 UI 可以直接与底层对象模型交互。由于您的客户不是直接的数据库实体，而是从注入的存储库中加载的，因此这似乎适合 Onion 的模型。

我在这里的假设是，客户实体实际上是通过注入的存储库组装的不同的、规范化的数据库实体的组合。

我的理解是，原则上，交互是通过抽象完成的，并且客户实体是客户数据库的抽象表示这一事实是有效的。

如果上述任何假设/想法不正确，请纠正我。

于 2014-02-20T16:25:21.417 回答
1

好问题。我有一个可能有用的例子。 https://bitbucket.org/jeffreypalermo/onion-architecture

对于使用核心域模型对象的简单应用程序就可以了。这些被设计成没有令人讨厌的依赖触角，因此它们工作得很好并且非常便携。它们可以跨越层而不会引起任何问题。

于 2014-02-21T21:38:49.287 回答