MVC 和 N 层架构

Question

我开始想知道在 MVC 模式中业务层应该在哪里。 这很快让我问“n-tier 和 MVC 之间有什么区别”。 我阅读了很多文章和 Stackoverflow 的回复，发现有很多不同的意见和回复。

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

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

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

刚刚阅读了有关 Angular 的文章，我可以看到 MVC 在 UI 层中实现，并看到 MVC 和 Web API 最近如何在 .Net 中合并，我可以看到带有控制器、视图和模型的 Web AP 中间层。

但这对 DL 来说是否成立？如今，.Net 中的大多数数据层都是带有一些包装的 EntityFrame 工作。 DL 层是否可以使用 MVC 模式实现，或者实际上应该这样实现？

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

任何人都可以给我任何指示是否可行，或者您是否应该对 DAL 是 MVC 感到困扰。

Answer 1

在某种程度上，是的。可以在数据层实现类似于 MVC 的东西。特别是视图、模型和控件（虽然不一定是控制器）。

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

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

Answer 2

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

请记住，您可以让多个控制器在 MVC 中指导/处理他们自己的视图和模型，那么当某些逻辑可能应用于其他控制器时（您最终会复制/复制代码）。

两种架构/设计模式都有各自的优势和局限性，个人使用两者，可以获得更大的灵活性和可扩展性。

在此处使用两种设计模式的混合模型查看我的应用程序架构图：

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