我开始想知道业务层应该在MVC模式中的哪个位置。 这很快让我问到＆＃34; n-tier和MVC＆＃34;之间的区别是什么？ 我阅读了很多文章和Stackoverflow的回复，发现有不同的意见，因为有回复。
我不是专家，但我认为有些回复和文章只是垃圾。例如 N层是每个层在网络中物理上不同的硬件上的时候（不！） N层适用于大型应用程序，MVC适用于小型（垃圾）
然后我读了一个有意义的。 N层进程总是将UI流向BL到DL，然后通过BL再次返回到UI。但是，MVC具有Triangular流程。没错，但这就是全部吗？
有人提出的另一点是MVC是一个应用程序架构模型，而n层是一个系统架构模式。我不确定他们的意思，直到他们提到作为应用程序架构的MVC模式可以在每个n层层中使用。
刚刚阅读了Angular我可以看到MVC正在UI层中实现，看看MVC和Web API最近是如何合并的.Net我可以看到一个带有控制器，视图和模型的Web AP中间层。
但这会阻碍DL吗？现在.Net中的大多数数据层都是EntityFrame，它包含了一些包装。 DL层可以用MVC模式实现，还是实际应该是？
如果N层和MVC的这个定义是正确的，那么应该可以将MVC模型应用于N层系统层中的任何层。
任何人都可以给我任何指示，如果这是可行的，或者你甚至应该被DAL作为MVC打扰。
答案 0 :(得分：0)
在某种程度上，是的。可以在数据层中实现类似于MVC的东西。特别是视图，模型和控件（不一定是控制器）。
以SQL Server为例。您可以创建一个消息传递体系结构，允许您创建一个API来访问数据，这样即使底层模型（表）发生更改，API也不会。
但请记住，“数据层”往往是指代码，而不是物理层。您的数据访问层通常是一个API，模型或存储库，它封装数据并将其转换为与应用程序层兼容的数据集。
答案 1 :(得分：0)
在 MVC 中，应用程序/业务层应该在控制器组件中，而对象应该在模型组件中，而 UI 应该在视图组件中。 在 MVC Web 应用程序中，控制器还应该处理 http GET 和 POST 请求并返回视图。 您还可以将 MVC 与 N 层结合起来……将业务逻辑放在不同的类中，将其从控制器中取出，特别是如果您需要在应用程序的不同部分应用/使用一个方法，这样您就可以调用它来自应用的任何控制器，减少重复代码并具有可维护的代码。
请记住，您可以让多个控制器在 MVC 中指导/处理他们自己的视图和模型，那么将业务/应用程序逻辑留在其中有什么意义，当某些逻辑可能应用于其他控制器时（您最终复制/重复代码）。
这两种架构/设计模式都有自己的优势和局限性，个人通过使用两者，您可以获得更大的灵活性和可扩展性。
在此处使用两种设计模式的混合模型查看我的应用程序架构图：