architecture - 三层架构依赖关系

Question

我一直在努力解决如何构建我的 3 层应用程序。我似乎总是遇到我不想要的依赖问题，这明确表明我做错了什么。

您通常如何构建 3 层架构？

我看到有两种方法之一:

1. 业务层位于顶部(或底部，取决于您如何看待它)，所有其他层都依赖于它。业务层定义完成其工作所需的接口(interface)，特别是数据访问。数据访问层实现这些接口(interface)，并使用依赖注入(inject)将它们注入(inject)到中间层。 UI 同样通过 DI 消耗输出接口(interface)。业务对象是数据层填充的 POCO。数据层没有自己的代码模型(它使用业务层中定义的业务对象)。业务层对 UI 或数据层一无所知，而 UI 和数据层则了解业务层。
2. UI 层位于顶部，业务层位于中间，数据层位于底部。数据层发布业务层使用的接口(interface)。业务具有 UI 使用的接口(interface)。这是一种直接的 1-2-3 局面。数据层定义代码对象，业务层有自己的模型(使用AutoMapper之类的东西在它们之间进行映射。但这种映射是在业务层中执行的)。数据层对业务层或 UI 层一无所知。业务层了解数据层，但不了解UI层。 UI层了解业务层，但不了解数据层。

您使用其中任何一个吗？哪一个？为什么？您使用不同的方法吗？

在我看来，#1 提供了一种以业务为中心的做事方法。 UI 可以轻松更改，数据层也可以轻松更改，而不会影响业务层。

第二个更直接，通常需要在数据层发生变化时也更改业务层。当然，您可以使用精心规划的接口(interface)来抽象它(例如存储库模式，但在某些地方需要更改)。 UI 可以更改，而不会影响任何一个。

Answer 1

如果它是一个业务逻辑很少的 CURD 应用程序，请使用方法 #2。 否则，使用方法 #1，它实际上是将控制反转 (IoC) 应用于方法 #2 的结果。