MVC的劣势是什么？[关闭]

自多年前开始真正组织代码以来，我一直在使用MVC / MV *。我使用它已经很久了，以至于我什至无法想到其他任何方式来构造我的代码，而成为实习生后我做的每一项工作都是基于MVC的。

我的问题是，MVC的劣势是什么？在什么情况下，MVC对项目来说是一个错误的选择，那么（更多）正确的选择是什么？当我查找MVC替代方案时，几乎每个结果都是不同类型的MVC。

为了缩小范围，使之不会关闭，对于Web应用程序来说。我确实在不同项目的后端和前端上工作，所以我不能只说前端或后端。

您应该永远记住-MVC是与UI相关的模式。如果要构建复杂的应用程序，则应将与UI不相关的所有内容从MVC三元组中带到任何其他类，子系统或层中。

这是我最大的错误。我花了很长时间了解这个简单的规则：

• 不要在整个应用程序中传播MVC模式，
• 将其限制为仅与UI相关的内容。

始终检查您编写的代码是否在逻辑上正确的位置，这意味着它在逻辑上适合您所在类的职责范围。如果不正确，请在理解后立即将其移开。

您称为MVC替代方案的所有模式（即Model-View-Presenter，Model-View-ViewModel）只是实现一般MVC概念的一种方式。

在我看来，MVC有两种类型-纯的和不纯的（因为缺少更好的词：）

纯粹的MVC是在闲聊中引入的：

这是用于个人计算/桌面应用程序的。如您所见，模型会将对它所做的任何更新/更改通知视图。（不纯净的）MVC并非如此。

为Web应用程序吹捧的另一个（不纯净的）MVC更像是PAC（表示抽象控制）模式，而不是上面的经典MVC。这更多的是代码组织和关注点分离：

• 型号：存储数据的抽象
• 控制：通常称为业务逻辑层，以及负责将HTTP请求路由到相应业务逻辑（又称为控制器）的应用程序的一部分
• 视图：通常是查看模板，这些模板格式化来自模型的数据并将其返回给客户端。模型从不向视图发送更新，视图也不会“订阅”模型的更新。这将是一场噩梦。因此，它更像PAC，而不是真正的MVC。

现在，这是Web应用程序通常的结构：

1. 前端：使用Backbone.js等框架的客户端上的 MVC，这本质上是“真正的” MVC形式。
2. 后端：同样，您的代码组织和关注点分离（不纯）存在MVC / PAC
3. 全局Web应用程序（对于整个Web应用程序）：如果您拥有仅返回JSON数据的RESTful后端，那么您的整个后端都可以被视为本质上是View和Controller的前端客户端应用程序的模型。

那么MVC有哪些缺点呢？嗯，这种模式经受了时间的考验，因此除了有点“复杂”之外，没有那么多重要的事情。您会看到，MVC是复合模式-实现策略/观察者模式，所有这些都安排得很好，形成了高级模式。

您应该在任何地方使用它吗？也许不吧。极其复杂的Web应用程序可能会分成多个层！您可能无法仅凭视图/业务逻辑/数据层就摆脱困境。总体框架/组织可能仍然是MVC风格的，但仅在宏观层面上。

在以下示例中，仅MVC本身可能是一个错误的选择：尝试为大型银行设计空中交通管制系统或贷款/抵押处理应用程序-仅MVC本身将是一个糟糕的选择。您将不可避免地拥有事件总线/消息队列，以及在各个层中具有MVC的多层体系结构，并可能具有总体MVC / PAC设计，以使代码库更好地组织。

许多人在设计模式上犯的错误是看到它在一个地方漂亮地工作，然后尝试将其应用到任何地方。

如果您在一个地方工作了一段时间，几乎可以通过查看当时流行的技术/设计模式/实践（例如单例/依赖注入/ TDD等）来约会一段代码。

至于哪里不使用它。好吧，无论MVC三元组中的哪一个元素都不适用。控制台应用程序可能根本不实现接口。应用程序可能没有模型。可以说，如果您既没有模型也没有视图，则不需要控制器。

问题很少出现在概念上，更多的是实现上。不管范式有多好，都要花点时间看一下它是否适合解决当前的问题。

就像不是您的开发平台不可或缺的任何范例一样，MVC的复杂性也在增加。缺点是您可能会关闭不应分开的单独类，并降低了它们紧密绑定的清晰度。（或者，对于琐碎的项目，甚至会混淆您的代码。）

第一个问题的替代方法是将这样的代码分成独立的子项目。第二种选择是在类或文件模型上的非分离代码。

我对应用MVC / MV *的理解是遵循关注点分离（SoC）的原理-将程序/代码分为不同的部分/部分，以便每个部分都可以解决单独的关注点（请参阅：http : //en.wikipedia.org / wiki / Separation_of_concerns）

分离关注点有很多好处：一个不会影响另一个，开发人员可以在一个单元上工作而不会影响其余部分，等等。等等。MVC不是遵循SoC的唯一模式，基本上，OOP本身就是将事物分解为单元的好主意。

MVC / MV *在处理与UI相关的开发时非常有用，而在其下可能还有更多的模式-工厂，单例，立面等。大多数大型项目由多层处理不同方面组成，但是UI不一定是必需的一些案例。您可能会看到很多MVC-这是因为很多项目都有UI元素。

因此，在谈论MVC的缺点时，它实际上取决于您正在执行的项目-它是否具有UI？是否需要出色的可扩展性/可扩展性？UI和后台系统之间有很多交互吗？例如，一个简单的信息网页根本不需要MVC，除非您打算将来将其扩展到一个很棒的交互式页面。

因此，为了评估MVC（或更笼统的设计模式），给它一个上下文，并考虑复杂性，可伸缩性，可测试性，维护性，时间约束等。