单元测试是MVC模式的主要目标吗？

最近在一次采访中，一个问题是“我们为什么要使用MVC？” 我刚刚回答说，它与许多现实世界中的系统非常接近！解释了它在可维护性，可伸缩性等方面所具有的好处。但是他们并没有说服他们，最后告诉我说MVC主要是因为它“使易于单元测试”而被使用。

虽然我知道他们的观点是正确的，但我仍然怀疑这是否是主要原因，因为（i）即使我决定不编写单元测试用例，MVC还是一个可能的选择（ii）许多有单元测试用例的GUI系统都没有按照MVC。

因此，问题是“单元测试是MVC模式的主要目标吗？”

编辑：我认为他们可能会提到测试驱动开发/编写NUnit测试用例的简便性。这是因为我们可以为模型编写测试用例（前提是视图恰好反映了模型的状态变化）-如果我错了，请纠正我。

主要目标是“关注点分离”，因为模型，视图和控制器都具有不同的职责。

在原来的施乐PARC论文作者指出：

MVC的基本目的是弥合人类用户的心理模型与计算机中存在的数字模型之间的鸿沟。

如果将单元测试作为主要目标，则可以轻松地对视图进行单元测试。纵观单元测试项目/框架的情况，将发现它与所提出的主张完全相反。通常将使用集成和功能测试来测试视图。

我认为答案是肯定的“否”。也许这是在这个特定组织中观察到的主要好处，但我不会将其称为“主要目标”。

我想以某种方式实现MVC并不会那么困难，这很难进行单元测试（哎呀，我第一次做它的方式几乎是不可测试的）。

另一方面，可以说几乎任何模式（不包括Singleton之类的东西）都可以促进单元测试，因为它们最常促进去耦-但这是他们的“主要目标”吗？几乎不。

MVC（就像大多数已知的设计模式一样）在单元测试开始之前就已经存在。GoF书于1994年出版-它们只是记录了已经使用了多年（如果不是几十年）的模式。（并且没有提及单元测试。）关于单元测试，我无法确定它何时成为“公开”的确切时间-我亲自在有关极限编程的文章和第一本XP书籍中阅读了它。于1999年问世。

因此，显然，单元测试不是发明/记录模式的主要目标-可以公平地说，如果应用得当，模式将极大地促进单元测试。

我认为不，简化单元测试是其中的好处之一，但是它是使用MVC时带来的好处的一部分，并列出了原因。说使用MVC的唯一主要原因是一个错误。听起来这家公司选择MVC来促进单元测试，因此他们认为这是主要原因。我个人使用MVC的原因是，与Web表单相比，它的简单性使其更易于设计和维护，但是每个人/公司都有使用任何技术的原因。

在ASP.NET MVC世界中，框架本身包括对ASP.NET的许多改进。这种设计模式的主要目的是将业务逻辑与用户界面隔离开来，以便专注于更好的可维护性，改进的可测试性和更清洁的应用程序结构。

ASP.NET MVC具有某些功能，如果您需要以下一项或多项，则使其成为最佳选择：

• 对生成的HTML的高度控制：与Web窗体不同，ASP.NET MVC中的视图完全按照您的指示呈现HTML。最近，Web窗体在此领域已得到改进，但仍不具备MVC的控制级别。

• 更容易的单元测试：使用ASP.NET MVC，可以很容易地遵循测试模式，例如测试驱动开发（TDD）。由于Web窗体中复杂的事件生命周期，因此在基于控件的框架之上，使用MVC可以使TDD变得容易得多。

• 关注点分离：这是指将系统的各个方面清楚地分开。由于其实现的模式，MVC应用程序分为离散的部分和松散绑定的部分（模型，视图和控制器），这使得维护变得容易。

其他好处包括：

MVC模式本身通过将应用程序的功能清楚地分为三个核心部分（模型，视图和控制器），使管理复杂性变得更加容易。

•ASP.NET MVC Web应用程序不使用视图状态或基于服务器的表单。这使MVC框架成为希望完全控制应用程序行为的开发人员的理想选择。视图状态可能会变得非常大，这对于像智能手机这样运行在慢速网络上的设备来说是个问题（传输所有信息可能会非常慢）。在Web窗体页面中，每个页面只能有一个。这是一个很大的限制。在MVC中，没有这样的限制-也就是说，您可以根据需要拥有任意数量的元素。

ASP.NET MVC为测试驱动的开发（TDD）提供更好的支持。

ASP.NET MVC非常适合大型开发人员团队支持的Web应用程序以及需要对HTML进行高度控制的Web设计人员。ASP.NET MVC请求处理