logo标签列表

MVC有哪些缺点？

model-view-controllerparadigms
9

我已经阅读了这里的一些问题和有关MVC的各种文章，可以看出它甚至可以应用于像绘画应用程序这样的GUI事件密集型应用程序。

有人能举出MVC可能不好的情况，并且其使用是不明智的吗？

编辑：我特别是在谈论GUI应用程序！

请查看：https://dev59.com/O0fRa4cB1Zd3GeqP7j8B - Bjorn
8个回答
27

我在我的网络内核驱动程序中尝试了MVC。然而，这个补丁被拒绝了。

2
哈，我正在考虑更新我的问题以指定GUI应用程序..！ - joshcomley
1
@Josh -- 我同意。目前这个问题有点像在问“哪些工作使用螺丝刀是不好的”，将问题限制在使用螺丝刀有意义的情况下，将会得到更好的答案。Aiden的回答很有趣，但除了指出这个工具的明显局限性外，没有什么特别有用的信息。 - tvanfosson
11

我认为你可能有些颠倒了。重点不是看你在哪里可以应用MVC这样的模式，而是学习这些模式并识别出当你要解决的问题可以自然地通过应用该模式来解决时。因此，如果您的问题空间可以自然地分成模型、视图和控制器，则它是MVC的一个很好的候选。如果您不能轻松地看出您的设计的哪些部分属于这三个类别，则可能不是适当的模式。

好观点。每次我找不到合适的方法时，通过谷歌搜索和阅读一些资料，最终找到了一种自然而有用的使用MVC的方式。 - joshcomley
1
+1 我同意MVC是问题类的描述，而不是该类之外的解决方案。 - Aiden Bell
4
MVC对于Web应用程序有意义。在Web应用程序中，您处理一些数据（例如：编写问题、添加评论、更改用户信息），您具有状态（已登录的用户），您没有许多不同的页面，而是有很多不同的内容适合这些页面。一个问题页面与一百万个问题。

例如，对于制作CMS，MVC是无用的。您没有任何模型，也没有控制器，只有带有装饰和菜单的文本页面。问题不再是处理数据-现在问题是正确地提供该文本内容。

尽管如此，CMS管理部分可以很好地建立在MVC之上，只是用户部分不行。

对于Web服务，最好使用REST，我认为这是一种独特的范例。

WebDAV应用程序也不会从MVC中受益很大。

Ruby在Web编程方面的限制是Rails更适合构建Web应用程序。我见过很多项目试图使用Rails创建WebDAV服务器或内容管理系统CMS，但都失败了。虽然你可以在Rails中创建CMS，但有更有效率的技术可以完成这项任务，比如Drupal和Django。事实上，如果你正在考虑Java门户开发，应该考虑使用Drupal和Django来完成任务。

为什么你不在CMS中使用模型？毫无疑问，CMS的每个“功能”都可以配备一个控制器。 - joshcomley
2
每个页面都有一个标识它的ID。它有相关的菜单、标题值和一些文本。你的控制器有一个按ID渲染页面的操作，它提取标题、相关菜单、文本和适当的模板（视图）。它使用给定的数据呈现所选视图。我不是说这是一个很好的匹配（部分原因是我没有考虑过），但你确实有一个模型。 - tvanfosson
这样，你每页就有十几个控制器（几个菜单控制器、头部控制器、内容控制器、旋转控制器），MVC框架可能不喜欢。 - alamar
脚本/生成脚手架页面 标题：字符串 正文：文本 类别ID：整数 页面模板ID：整数 -- 需要一些创意路线，但是这就是它。在我看来，MVC比像PHP或ASP这样的东西更适合CMS，因为所有页面都基于数据库中的数据，而不是实际文件。 - Matt Briggs
有实际参数吗？链接呢？ - alamar
显示剩余7条评论
2

如果你想要引入第三方组件，那么在MVC模式下工作会变得困难。一个很好的例子是CMS。

每个组件都有它们自己的控制器对象，你将无法共享模型到用户界面的控制。

取决于第三方组件是否构建为在MVC环境中运行。它们可以被构建为与特定模型一起工作，而不需要单独的控制器，您自己的控制器/操作提供所需的模型即可。我已经有了一些用户控件的实例，这些控件最终可以重构为通用组件。 - tvanfosson
请参考 Typo3 插件树或 Vanilla 的 Garden 框架，了解它们如何在 PHP 中解决此问题。 在 Ruby/Rails 中，您可以使用 mixins/modules 来继承“常见”的 Controller 代码。 如果您想重用用户身份验证，则可以在 Controller 本身中使用过滤器或在框架的 Application/Base controller 中声明您的代码。 总之：只有当第三方组件没有经过深思熟虑的接口时，与其一起工作才会变得困难。 - Radek
1

我并不确定MVC在GUI应用程序中真的是一个坏主意。但是有一些替代方案可以说是更好的（也可以说是更糟糕的，这取决于你问的人的意见）。最常见的是MVP。请参阅此处的解释：Everything You Wanted To Know About MVC and MVP But Were Afraid To Ask。

虽然我认为如果您正在使用未考虑MVC的软件框架或其他交互式软件，则使用MVC可能是一个坏主意。

换句话说，这很像比较编程语言。通常没有多少任务可以说哪个更好。这通常归结为程序员的偏好、库的可用性和团队的经验。

1
MVC不应该在性能关键的应用程序中使用。我不知道随着计算能力的增加是否仍然适用，但一个例子是呼叫中心应用程序。如果您可以节省每个呼叫输入和更新信息的0.5秒，那么这些储蓄会随着时间的推移而累积。为了从您的应用程序中获得最后一点性能，您应该使用桌面应用程序而不是Web应用程序，并直接与数据库通信。
1
Stackoverflow是使用MVC架构构建的，Jeff曾经表示性能至关重要。SO的速度非常快，所以我认为性能不是一个问题。 - Alex
根据我的经验，MVC有助于良好的实践，并且我从未见过使用MVC范例本身会导致性能开销。 - joshcomley
0

什么时候是不好的呢？当有另一种代码结构更适合您的项目时。

有无数的项目，MVC并不适用，但我不认为列出它们会有任何好处。

如果MVC适用，请使用它；如果不适用，请使用其他东西。

我不是在寻找应用程序列表，而是在寻找一些通用的理由来解释为什么不使用MVC。 - joshcomley
-8

MVC和ORM都是笑话……只有在你的应用程序不是数据库应用程序时，或者当你想保持应用程序数据库无关性时才适用。如果你正在使用支持存储过程的RDBMS，那么这是唯一的方法。存储过程是经验丰富的应用程序开发人员首选的方法。MVC和ORM只是被试图销售与这些技术相关的产品或服务的公司所推广（例如微软试图销售VS）。停止浪费时间学习Java和C#，而是专注于真正重要的Javascript和SQL。

1
那么，经验丰富的开发者先生...我想我应该学习如何使用SQL和Javascript来编写网络驱动程序？ - Arafangion
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接