model-view-controller - MVC - 是否存在不相关或不合适的情况？

Question

在开发具有 GUI 和数据库访问权限的应用程序时，是否存在与 MVC 架构无关的情况？

在我看来，视图和控制器似乎只能是不同的实体，以升级视图或用其他东西替换它们，即移动显示器（或预测应用程序未来可能发生的变化）。

此外，我认为只有在要升级/更换模型时才需要模型和控制器的分离。

那么 MVC 架构是否还有其他目的，即组件应该升级/更改的情况，或者真的是这样吗？

Answer 1

我认为，您困惑的根源在于您尝试应用 MVC 设计模式的范围。

MVC 不是小型应用程序的模式。相反，当您的自由格式 OOP 代码开始变得难以管理时，您应该应用它。您的代码库可能正在实现所有SOLID 原则，但在某些时候您会开始迷失在那里。

那是你应该使用 MVC 的时候，因为这种设计模式应用了额外的约束。它不会向应用程序添加任何新内容。相反，它限制了哪些代码可以进入应用程序的哪些部分。

_{PS您似乎也误解了MVC中的分离。基本的分界线是模型层和表示层。这些是 MVC 应用程序的两个主要部分。只有这样，在表示层中才会有视图和控制器之间的分离。您可能会从阅读这篇文章中受益。}

Answer 2

我喜欢 MVC，因为它可以更容易地思考应用程序的不同部分将如何协同工作。如果一切都集中在一起，我会发现在我的脑海中更难想象。

所以这并不是你应该在什么时候使用它，而是你更喜欢如何思考？

如果您发现不使用 MVC 更容易，那么您可能不应该使用 MVC。

Answer 3

MVC 架构有一些好处，也有一些缺点。您必须为您的项目权衡它们，看看哪个最适合您。

MVC 的优点：

• 更易于维护，因为它是分隔的（关注点分离）。
• 它更易于测试，因为您可以对控制器进行单元测试。
• 您通常可以更好地控制生成的 HTML（是的，您可以使用 webforms 完成相同的操作，但前提是您也放弃了 webforms 的所有优势）。
• 您的网页将更小更快，因为您不会携带页面/视图/控制状态。
• 与客户端生活方式和库（Bootstrap、jQuery 及其许多插件、AJAX 等）更好地集成

网络表单的优点：

• 更多 3rd 方控件（webforms 严重依赖 3rd 方控件或自定义用户控件来实现快速应用程序开发）。
• 如果您需要视图状态，则需要较少的工作，但如果设计正确，这非常罕见。
• 与服务器端控件库更好地集成。

当然，有人会说，你为什么将 xyz 列为优势，因为你也可以在另一个方面做到这一点！好吧，您可以在两个框架中实现相同的目标，这只是一个简单的问题。对一个人来说容易的事情在另一个人身上可能会更困难，但只要有足够的时间和资源，他们俩也可以做到。

Answer 4

对我来说，这一切都归结为可测试性。与模型代码的测试相比，UI 代码的自动化测试非常昂贵。与视图层相比，在模型层和事件控制器层中实现测试覆盖要容易得多。

如果您不需要测试您的应用程序，并且它足够小，您可以将其全部记在脑海中，那么 MVC 可能是在浪费时间。很少有应用程序真的足够小，以至于这些问题都不是问题。但如果应用程序真的那么小，MVC 将增加的开销远远超过它提供的价值。

Answer 5

不要将MVC设计模式视为您的业务架构。视为MVC演示架构。MVC在业务架构方面有很多关于使用的争论。这个stackoverflow 问题就是一个例子。

实际上，您正在寻找N-Tier建筑。它被分隔为DAL,BLL和PL:

数据访问层 (DAL)：

负责与存储交互的层（插入/更新/删除）

BLL：

业务逻辑所在的层。这一层是您的应用程序的核心。有些人经常使用术语中间件（如果有错误请纠正我）来表示BLL. BLL 不知道 UI，意味着它可以被桌面应用程序、Web 应用程序、移动应用程序等使用。

PL：

这是您的表示层或 UI 层。MVC，至少ViewandController驻留在此处。

Answer 6

MVC 是关于分离关注点并使这些关注点可测试。

有人说“MVC 不是小型应用程序的模式。”。我不同意。为什么？它只规定了您如何分离关注点，我不明白为什么这对于小型应用程序应该有所不同。我认为它更简单，因为每个开发人员都使用相同的模式并且已经习惯了。这不是开销，而是一致性。也看看这人怎么说。

另一件事：MVC 是一种表示层模式（Separated Presentation），这意味着它在逻辑上将您的 UI 分离为模型、视图和控制器。控制器负责管理流程，与后端系统交互以查询和保存数据，并将该数据转换为视图使用的模型（或视图模型）。

后端本身是另一个系统，它有自己独立的架构，有服务、域和数据层（例如洋葱架构，可以在这里找到一个例子）。