3层架构依赖

Question

我一直在努力构建我的3层应用程序。我似乎总是遇到我不想要的依赖性问题，这是一个肯定的迹象，表明我做错了。

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

我看到了以下两种方法之一：

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



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

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

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

Answer 1

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