MVC在哪里是件坏事？

Question

我一直在阅读有关MVC的几个问题以及关于MVC的各种文章，并且可以看到它甚至可以应用于GUI事件密集型应用程序，如绘图应用程序。

任何人都可以引用MVC可能是坏事并且使用不明智的情况吗？

编辑：我在这里专门讨论GUI应用程序！

Answer 1

我在网络内核驱动程序中尝试了MVC。补丁被拒绝了。

Answer 2

我认为你看起来有些倒退。关键是要看看你可以在哪里应用像MVC这样的模式，重点是要学习模式并确定何时可以通过应用模式解决你试图解决的问题。因此，如果你的问题空间可以自然地分为模型，视图和控制器，那么它是MVC的一个很好的候选者。如果您无法轻易看到设计的哪些部分属于这三个类别，则可能不是合适的模式。

Answer 3

MVC对Web应用程序有意义。 在Web应用程序中，您处理一些数据（在SA：写问题，添加注释，更改用户信息），您有状态（登录用户），您没有很多不同的页面，但有很多不同的内容适合那些页面。一个问题页面与一百万个问题。

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

首先，CMS 管理员会建立在MVC之上，只是用户部分不会。

对于Web服务，您最好使用REST，我相信这是一个独特的范例。

WebDAV应用程序也不会从MVC中受益匪浅。

The caveat on Ruby for Web programming是Rails更适合构建Web应用程序。我已经看到很多项目尝试使用Rails创建WebDAV服务器或内容管理系统CMS并且失败了。虽然您可以在Rails中执行CMS，但是有更高效的技术可用于该任务，例如Drupal和Django。事实上，我想说如果你正在研究Java Portal开发工作，你应该评估Drupal和Django的任务。

Answer 4

任何你想要放入第三方组件的东西都会让你很难在MVC模式中工作。一个很好的例子是CMS。

您获得的每个组件都将拥有“自己的”控制器对象，您将无法共享模型的“控制” - ＆gt; ui路过。

Answer 5

我不一定知道MVC对GUI应用程序来说真的是一个坏的想法。但是有些替代方案可以说是更好的（并且根据你们的意见而言，也可能更糟糕）。最常见的是MVP。请参阅此处获取解释：Everything You Wanted To Know About MVC and MVP But Were Afraid To Ask。

虽然我认为如果您使用的是框架或者与未使用MVC设计的软件进行交互，那么使用MVC可能是一个坏主意。

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

Answer 6

MVC不应该用于性能至关重要的应用程序。我不知道这是否仍适用于计算能力的增加，但一个例子是呼叫中心应用程序。如果每次通话可以节省0.5秒，输入和更新信息，这些节省会随着时间的推移而增加。要从应用程序中获得最后一点性能，您应该使用桌面应用程序而不是Web应用程序，并让它直接与数据库对话。

Answer 7

什么时候不好？哪里有另一个更适合你项目的代码结构。

有无数的项目，MVC不会“适合”，但我不知道它们的列表将如何有任何好处..

如果MVC适合，请使用它，如果没有，请使用别的东西..

Answer 8

MVC和ORM是一个笑话......它们仅适用于您的应用程序不是数据库应用程序，或者您希望保持应用程序数据库不可知的情况。如果您正在使用支持存储过程的RDBMS，那么这是唯一的方法。存储过程是经验丰富的应用程序开发人员的首选方法。 MVC和ORM仅由试图销售与这些技术相关的产品或服务的公司（例如微软试图销售VS）推广。不要浪费你的时间学习Java和C＃，而是关注真正重要的东西，Javascript和SQL。