MVC - 是否有不相关或不合适的情况？

Question

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

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

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

MVC架构还有其他任何目的，即应该升级/更改组件的情况，还是真的呢？

Answer 1

我喜欢MVC，因为它可以更容易地思考应用程序的不同部分如何协同工作。如果把所有东西都集中在一起，我发现在脑海中想象的难度要大得多。

所以这不是你何时应该使用它的情况，而是你更喜欢怎么想？

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

Answer 2

我认为，您混淆的根源是您尝试应用MVC设计模式的范围。

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

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

  

_{P.S。你似乎也错误地认为MVC中有什么分离。基本鸿沟在模型层和表示层之间。这些是MVC应用程序的两个主要部分。只有在表示层之后，视图和控制器之间才会分离。您可能会从阅读this article。}

中受益

Answer 3

对我而言，这一切都取决于可测试性。与测试模型代码相比，UI代码的自动测试过于昂贵。与视图层相比，在模型和事件控制器层中实现测试覆盖要容易得多。

如果您不需要测试您的应用程序，并且它足够小以至于您可以将它全部保持在脑中，那么MVC可能是浪费时间。很少有应用程序真的足够小，以至于这些问题不是问题。但是，如果应用程序真的那么小，MVC将增加比它提供的更多的开销。

Answer 4

不要将MVC设计模式视为业务架构。将MVC视为演示架构。在业务架构方面，有许多关于MVC用法的论点。这个stackoverflow question就是一个例子。

实际上，您正在寻找N-Tier架构。它被分隔为DAL，BLL和PL：

数据访问层（DAL）：

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

<强> BLL：

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

<强> PL：

这是您的表示层或UI图层。 MVC，至少View和Controller驻留在这里。

Answer 5

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

MVC的优点：

• 更易于维护，因为它是分隔的（分离 问题）。
• 它更容易测试，因为你可以对控制器进行单元测试。
• 您通常可以更好地控制生成的HTML （是的，您可以使用webforms完成相同的操作，但仅限于您提供 了解webforms的所有优点）。
• 您的网页会更小更快，因为您不会 携带页面/查看/控制状态。
• 更好地与客户端生活方式和图书馆相结合 （Bootstrap，jQuery和它的许多插件，AJAX等）

网络表格的优点：

• 更多第三方控件（webforms严重依赖第三方控件或自定义用户控件来实现快速应用程序开发）。
• 如果你需要viewstate，那么它需要的工作量更少，但这很漂亮 如果设计正确，则很少见。
• 与服务器端控件库更好地集成。

当然，有人会说，为什么你把xyz列为优势，因为你也可以在另一个中做到这一点！好吧，你可以在两个框架中实现同样的目的，这只是一个轻松的问题。对另一个人来说容易的事情在另一个人身上可能会更加困难，但是如果有足够的时间和资源，两者都可以做到这一点。

Answer 6

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

有人说＆＃39; MVC不适合小型应用程序。＆＃39;。我不同意。为什么？它只能决定你如何区分问题，我不明白为什么这对于小型应用程序应该有所不同。我认为它更简单，因为每个开发人员使用相同的模式并习惯它。这不是开销，而是一致性。另请查看this guy必须说的内容。

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

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