在1层应用程序即Mvc中，你会得到一个名为models的文件夹，你可以在那里构建和存储你的类，我知道从我所读到的三层应用程序来看它似乎是正确的存储业务层（第二层）内部的模型，以及UI（第一层），我将向第二层添加项目引用，这将允许我使用模型并调用方法。
从第二层看，它会调用数据层（第三层）并对数据库执行crud操作，但是数据层需要业务层的模型，所以当我尝试从数据层添加项目引用时到业务层我得到错误
无法添加对“业务层”的引用，将此项目添加为引用会导致循环依赖
我通过业务层到数据层已将其理解为参考
我如何解决这个问题？在数据层中创建其他模型并使用数据库中的结果填充它们并将其传递回业务层，然后将其传递回UI？我对此感到有些困惑。
**更新**
从我读过的数据层到业务层内的参考模型，我需要进行模型映射，我的模型映射会非常大，所以我想要包含第4层，这将是一个共享库这将包括数据层和业务层可以在需要时访问模型的所有模型。
答案 0 :(得分：0)
你走在正确的轨道上但我发现更容易将模型层视为数据（第三层），控制器（业务层，第二层）管理ui之间的数据流（第一层）和数据层。
如果以这种方式修改架构，则应该删除循环引用。
这也允许您将数据层对象映射到中间层的适当的更少/更复杂的结构，从而简化了UI显示的界面并将业务逻辑封装在那里。
答案 1 :(得分：0)
有点偏离主题但是......
根据应用程序的大小，可能没有理由引入不必要的复杂性来尝试并遵循您可能不一定理解的模式。这样做会让你更加头痛。
话虽这么说，如果您的项目规模很大并且需要一些良好的组织，我强烈建议您进行更多的研究，也许还有一些示例项目，您可以在那里尝试您想出的架构。你第一次没办法做对。
我个人建议查看“洋葱架构”而不是“ n-tier ”，当然你会发现很多不同的观点。你必须做出自己的决定。
这是我开始使用的通用设置。
<强>核心即可。它知道没有其他项目。这是您的“业务”课程的去处。如客户，产品，订单等
数据即可。它了解Core。它负责接收Core对象并将其存储在某个地方。就是这样。
<强>服务即可。它了解核心和数据。它的工作是公开诸如“创建客户”之类的方法，它将负责创建客户并存储它。
Web / Api / Mvc 。这将了解服务。它的工作是向用户公开您的服务。 （UI等）。 （它也可能知道核心/数据......但这是一个更大的讨论。）