MVC和N-Tier架构

Question

我一开始想知道业务层应该在MVC模式中的什么位置。这很快让我问道：“n-tier和MVC有什么不同”。我读了很多文章和Stackoverflow回复，发现有多少回复就有多少不同意见。

我不是专家，但我认为一些回复和文章都是垃圾。例如，N层是指每个层位于网络中物理上不同的硬件上(不！)N层适用于大型应用程序，而MVC适用于小型应用程序(垃圾)

然后我读了一篇有意义的文章。N层流程总是将UI流到BL再到DL，然后再通过BL返回到UI。但是，MVC具有三角形过程流。没错，但这就是全部吗？

有人提出的另一个观点是，MVC是一种应用程序体系结构模型，n层是一种系统体系结构模式。我不确定他们所说的是什么意思，直到他们提到MVC模式是一种应用程序架构，可以在n层的每一层中使用。

读过Angular之后，我可以看到MVC是在UI层实现的，也可以看到MVC和Web最近是如何在.Net中合并的，我可以看到一个包含控制器、视图和模型的Web中间层。

但这能支撑起DL吗？如今，.Net中的大多数数据层都是带有一些包装的EntityFrame。DL层是否可以使用MVC模式实现，或者实际上应该是这样？

如果N层和MVC的这个定义是正确的，那么应该可以将MVC模型应用于N层系统层中的任何层。

有没有人能告诉我这是否可行，或者你是否应该为DAL是MVC而烦恼。

Answer 1

在某种程度上，是的。在数据层实现类似于MVC的东西是可能的。尤其是视图、模型和控件(不一定是controllerER )。

以SQL Server为例。您可以创建一个消息传递体系结构，该体系结构允许您创建一个API来访问数据，这样即使底层模型(表)发生变化，API也不会发生变化。

但是请记住，“数据层”倾向于引用代码，而不是物理层。数据访问层通常是一个API、模型或存储库，用于封装数据并将其转换为与应用层兼容的数据集。

Answer 2

在MVC中，应用程序/业务层应该在控制器组件中，而对象应该在模型组件和视图组件中的UI中。在MVC web应用中，控制器还应该处理http GET和POST请求以及返回视图。您还可以将MVC与N层…结合使用。将业务逻辑放在一个或多个不同的类中，将其从控制器中移除，特别是当您需要在应用程序的不同部分应用/使用方法时，这样您就可以从应用程序的任何控制器调用它，减少重复代码并拥有可维护的代码。

请记住，您可以让多个控制器在MVC中指导/处理它们自己的视图和模型，因此，当某些逻辑可能应用于其他控制器时(您最终会复制/复制代码)，将业务/应用程序逻辑留在其中有什么意义。

这两种架构/设计模式都有自己的优点和局限性，就个人而言，通过使用这两种架构/设计模式，您可以获得更大的灵活性和可扩展性。

在这里看一下我的应用程序架构图，它使用了两种设计模式的hyrbid模型：

https://www.reddit.com/r/dotnet/comments/d1e6ha/a_diagram_of_an_mvc_ntier_hybrid_model_which_i/?utm_source=share&utm_medium=ios_app&utm_name=iossmf