三层应用

Question

在 1 层应用程序（即 Mvc）中，您会获得一个名为 models 的文件夹，然后在其中构建和存储您的类，我知道当涉及到我所阅读的三层应用程序时，存储业务层（第 2 层）内部的模型，以及 UI（第 1 层）我将添加对第 2 层的项目引用，这将允许我使用模型并调用方法。

从第二层的角度来看，它会调用数据层（第三层）并对数据库执行 crud 操作，但是数据层需要来自业务层的模型，所以当我尝试从数据层添加项目引用时到业务层我得到错误

无法添加对“业务层”的引用，将此项目添加为引用会导致循环依赖

据我所知，已经通过业务层对数据层进行了参考

我将如何解决这个问题？是否在数据层中创建其他模型并使用数据库中的结果填充它们并将其传递回业务层，然后再将其传递回 UI？我对此有点困惑。

** 更新**

从我读过的数据层到业务层中的参考模型，我需要做模型映射，我的模型映射会很大，所以我正在考虑包括一个共享库的第四层这将包含所有模型，数据层和业务层可以在需要时访问模型。

Answer 1

有点跑题了，但是...

根据您的应用程序的大小，可能没有理由引入不必要的复杂性来尝试遵循您可能不一定理解的模式。这样做会让你更加头疼。

话虽如此，如果您的项目规模很大并且需要进行良好的组织，我强烈建议您进行更多的研究，也许可以在其中尝试您提出的架构的一些示例项目。你不可能第一次就做对了。

我个人建议研究“onion architecture”而不是“n-tier”，当然你会发现很多不同的观点。您必须自己做出决定。

这是我开始使用的通用设置。

核心。它不知道其他项目。这是您的“业务”课程去的地方。例如客户、产品、订单等。

数据。它知道Core。它负责接收一个核心对象并将其存储在某个地方。就是这样。

服务。它知道核心和数据。它的工作是暴露诸如“Create Customer”之类的方法，它会负责创建一个客户并存储它。

Web/Api/Mvc。这将了解Service。它的工作是将您的服务公开给用户。 （用户界面等）。 （它可能也知道 Core / Data ......但这是一个更大的讨论。）

Answer 2

您在正确的轨道上，但我发现将模型层视为数据（第三层）更容易，控制器（业务层，第二层）管理 ui（第一层）之间的数据流) 和数据层。

如果你以这种方式修改你的架构，你应该摆脱循环引用。

这还允许您将数据层对象映射到中间层的适当的不那么/更复杂的结构，从而简化显示给 UI 的界面并封装那里的业务逻辑。