3层架构依赖

Question

我一直在为如何构建我的 3 层应用程序而苦苦挣扎。我似乎总是以我不想要的依赖问题告终，这肯定表明我做错了。

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

我看到了两种方法之一：

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

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

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

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

Answer 1

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