我需要向非程序员解释MVC。即，在进度报告的范围内，致其他部门的经理。我要做的一件事是将我们的代码库重构为MVC分离。

他们可能会问什么是MVC分离？他们可能会问为什么需要它？

在阅读了这样一个相当技术性的答案之后： 真正的MVC是什么？，我并不完全满意，因为我将与非程序员交谈。他们可能会点头，但他们可能不明白这是什么以及为什么需要它。

实际上，除了“为了提高对软件进行更改的灵活性而将关注点，职责，功能，类，块，任务，事物分开）之外，我还没有完全掌握MVC的含义。我认为使用DI和OO工具和技术将数据库从视图中分离出来，并将视图从业务逻辑中分离出来，我认为这是MVC分离。

因此，下一次您向具有销售和会计背景的非程序员讲解MVC时，您会告诉他们什么？

您不解释MVC。

您所做的解释是，这是代码库的重组。

重组可以简化代码库，从而使开发人员可以更快，更好地更改错误报告和功能请求，而减少错误。

他们不需要知道技术细节，只需知道为什么要做，什么可以做以及业务如何受益。

换句话说-跟他们说语言。

尽管我支持Oded的回答的要点，即您应该用“他们的语言”向业务经理解释技术项目，但我对“他们不需要知道技术细节，而知道这样做的原因”感到不满。

如果您正在与部门负责人进行项目或投资审查会议，并且宣布“这就是我们正在做的事情”，那么他们可能会问：“嗯……为什么？这似乎是对时间和精力的大笔投资。您能给我们更多的了解您在做什么以及为什么吗？” 这似乎是一个非常合理的问题。您不想被困在“嗯...很复杂”的位置。或“不，我无法真正解释。” 或“别担心。” 您要进行项目审查的人员越高级，他们越不可能让“这只是我无法很好地解释的事情”。如果您可以更深入一点，使其他人感到舒服，那就更好了：1）您知道自己在做什么

因此，在您的后兜里准备好MVC的草图，随时可以使用。就像是：

“这有点技术性，但是... MVC将代码分为模型（负责核心数据和业务逻辑），视图（显示数据）和控制器（处理用户交互和更新）。这是一种经过验证的体系结构， -可能是软件工程最成功的“设计模式”。我知道它看起来可能只是“有点麻烦”，但要处理所有传入的请求，我们需要一个更坚实的基础，这将使我们处于正确的基础上来构建新的功能并更快地解决错误。”

即使他们在最后没有完全理解MVC，并且即使您不得不简化以使其易于理解（“打碎鸡蛋制成煎蛋卷”），我也会打赌您会发现它更加舒适准备好解释，而不是向高级经理说“我无法解释”或“您没有资格理解”。

为了提高对软件进行更改的灵活性

管理人员对最终结果感兴趣。技术越少，他们对您如何到达那里的可能性就越小。MVC是非常普遍，流行和证明的。

将来发出更改请求时，您可以让管理层知道可以更轻松，更快地进行更改。每个人都喜欢听到这个。

这是一种常见的策略，因此雇用新开发人员应该不会有问题。实际上，您可能会吸引有力的更好的开发人员。

如果在这个特定项目中存在许多紧迫的问题，这将是非常困难的。他们可能不想退后一步，所以您可以前进两步。解决方案可能是等待或更小规模地实施。

• 型号-电线/电力
• 视图-灯具
• 控制器-电灯开关

相对容易切换出组件（灯具，照明开关/调光器）。也许不需要太多的接线，但是仍然可以在不影响其他组件的情况下完成接线。每个人都应该能够在自己的脑海中看到它，甚至是营销/销售类型。（清除分隔等）

现在告诉您的老板/同事，在我们的应用程序/系统中，开关嵌入在灯具内，并且灯具用铜线包裹。现在想象一下尝试更新灯具，开关或电线。代价非常高，对其他组件的影响非常大，并且可能很危险而又不会破坏其他功能。

MVC在代码库中应用了一种模式，该模式将混乱的（但有效的）混乱转变为可以更快，更轻松，错误更少的方式进行更改。

一种简单的方式来理解MVC：该模型是数据，该视图是在屏幕上的窗口，和所述控制装置是这两者之间的粘合。

有史以来最好的记录：“我们需要SMART模型，THIN控制器和DUMB视图”

与其他软件设计模式一样，MVC表示问题的“ 解决方案核心 ”，同时允许其适用于每个系统。最好将其视为一个概念，而不是特定的实现。有许多概念的实现。

所有MVC变体都使用相同的组件划分，但是通常它们在组件交互方式上有所不同。

对于那些不了解的人，MVC最初是由Trygve Reenskaug于1979年使用Smalltalk的设计模式来描述的。他的论文以“ Smalltalk-80中的应用程序编程：如何使用模型-视图-控制器”为标题发表，并为将来的大多数MVC实现奠定了基础。

我对Ode​​d表示半信半疑-学习如何说服非技术同事和经理您正在做的事情是重要且有用的，而无需说明具体细节，这是您明智地发展的必要技能。

但是，我相信具有用简单的术语解释复杂概念的能力实际上对此有所帮助-非技术经理经常遇到的一个问题是，由于他们难以准确地了解技术人员的工作方式，因此他们倾向于不信任他们。这只是人的本性：相信自己不了解的东西比相信自己更容易，是没有用或错误的。因此，如果您可以随意使概念易于理解，则可以在需要时使用它，并且随着时间的流逝，您的非技术经理会了解到，如果愿意的话，他们可以理解它-您不会无所适从对他们-您只是为了他们的理智而保留了他们的细节。他们会更加信任您。

除此之外，让我们回答这个问题：

我发现使用商人理解的类比很有用。对于MVC，我将其描述为业务。

• 模型负责业务逻辑和数据-它们是定义程序做什么以及如何执行程序的细节。如果程序是企业，则模型将是仓库，工厂，工人和固定设备。他们还将是确保遵循规则并执行策略的下层管理者。
• 视图是表示层- 视图向用户显示了系统中正在发生的事情，并提供了与程序进行交互的方式。如果我们的程序是一家公司，则视图将像是陈列室地板，贸易会议上的销售摊位或销售代表。它们显示选项，提供用户友好的信息和反馈，并将请求返回给公司。
• 控制器是协调层-他们确保信息从模型传递到视图，反之亦然，并且确保所有东西协同工作以完成工作。如果该计划是一家公司，那么控制者将是中高层管理人员。他们并没有过多地参与细节工作，但是他们确保合适的人拥有合适的工具来完成工作，并且会批准或拒绝高层决策。它们提供了总体方向，以便事物可以协同工作。

用这样的类比来解释它的好处是，一个好的经理将看到以这种方式分离问题的智慧，并可能决定他们应该更像控制器，而不是在将来不参与细节！

希望可以回答“是什么”-用这样的类比也很容易：

想象一个理想的公司，其中每个部门负责一组任务，并且知道它将始终拥有所需的资源，而不必担心其他人在做什么。销售代表找到客户，获得他们的订单，将其传递回批准的管理层，然后去仓库/生产/工程部门进行履行。反馈是直接的-除非有问题，否则没有其他人需要参与。这是一个很好的MVC设计-每个部分都有工作，而不必担心其他部分。这样，如果需要我们就可以轻松进行更改。在非MVC设计中，职责不明确。当客户要求不同的东西时，销售代表可能会尝试修改产品。或者，他们可能会根据当天的感受给出不同的价格。当首席执行官应该担心如何建立更可靠的供应链时，CEO可能会陷入混乱的生产线。仓库工人应该在销售现场与客户交谈，以使他们应该履行已经接受的订单。

换句话说，良好的MVC设计可以使每个部分专注于一件事，以便它可以正确地完成工作-就像组织良好的公司一样。

**免责声明-如果您的公司组织不善，可能会因此而冒犯。在这种情况下，您将需要另一个类比。您可能还需要其他工作。

MVC的好处主要在于关注点分离：

它使人们能够专注于自己的长处。

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

它可以降低成本，因为相互交织的系统要求工作人员必须是所有这些领域的专家，或者当一个领域的变更影响到另一个领域时，您更有可能遇到问题。

提供MVC架构的真实示例：手机，台式电话，Skype等。更改视图（拨号盘，扬声器，麦克风的类型）不会影响模型（音频信号），控制器是其中的电路将声波转换为音频信号的电话。

我会告诉他们，MVC分开了我的关注点。

我首先关心的是代码逻辑-我在幕后做的事情，以使网站执行他们希望执行的操作。

我的第二个问题是业务逻辑-他们（用户）希望应用程序执行的操作。

我的第三个问题是网站的外观-他们访问的页面可以完成他们想要的事情。

（我不会在下一部分告诉他们）因此，按顺序，我的解释是关于Model，Controller和View的。

说明优势

我将以商业利益来解释MVC。您的经理将能够理解这一点，并且在优势令人信服时会加入。

MVC允许您将应用程序细分为明智的单元，每个单元独立存在。您将获得干净，可维护，可测试的代码，并可能在系统之间重用代码。

该模型

每个模型都封装一种类型的业务信息，例如客户记录或产品，以及所有相关的业务逻辑。

分开进行此操作可使您轻松地与应用程序的其他部分隔离地测试业务逻辑。

您还可以通过添加其他模型来轻松扩展应用程序，它非常模块化且简洁。

理论上每个模型可以独立于其他模型存在。您可能考虑通过使用服务对象来处理模型之间的关系来强制执行此操作。您可以交换模型而不会影响系统的其余部分。

风景

分开视图可以使您轻松更新前端，而不会破坏底层后端。

您可以将前端代码提供给其他开发人员，而不必让他们访问整个系统。

您还可以自由创建与现有系统一起使用的替代前端。您可以将数据显示为移动应用程序，API，PDF或Excel电子表格。您可以执行此操作，而无需侵入系统的其余部分。您不太可能意外破坏东西。您可以轻松创建集成点，以供现有系统使用。

控制器

控制器将模型连接到视图。它使一切分离。您可以非常轻松地连接其他视图。如果更改模型代码，则甚至不需要知道视图。

其他优点

这是一种常见的模式。其他开发人员将能够理解您的代码并对其进行处理。如果几年后返回代码，您将可能能够理解并进行更改。您的代码将不太可能成为将来的开发人员的又一个传统难题。

因为所有内容都有位置，所以生成清晰的代码要容易得多。意大利面条化的风险大大降低（尽管没有消除）。您的代码变得可维护。

因为一切都是模块化的，所以您可以单独测试它的各个部分。您的代码是可测试的，并且不太可能包含错误或安全漏洞。将来的升级将更加容易，因为您将能够轻松测试整个系统。