在我的公司，我们即将使用 ASP.NET MVC 构建一个新站点。我的老板（营销人员）想了解更多有关该技术的信息，所以我试图找到一个非常好的、简单且具有教学意义的 MVC 概念演示，但没有任何运气。他们中的大多数都需要相当多的编程基础知识。
有什么好的视频、幻灯片或其他建议吗？
【问题讨论】：
标签： asp.net-mvc
Craig Strong 有一篇非常不错的文章，介绍了 MVC 的总体情况以及如何解释它对业务的好处。在这里查看：Updated link。
通俗地定义 MVC
请记住，您具有技术头脑并且接近代码。 MVC 给你 像白天一样清晰，但对业务说“模型，视图， Contoller' 可能会给他们一种你正在遭受痛苦的印象 一些形式的抽动秽语综合征。 MVC 对企业来说意义不大 在您根据代码定义它们之后。为了让业务 理解为什么这是答案，最重要的是它是什么，可以是 根据我的经验，这项任务比预期的要多。甚至有些人 开发人员有时难以理解这一点。
为了让听众了解 MVC 是什么以及它为什么起作用 在pass中尝试过的是将MVC应用到不同的行业 听众有更多的参与。一个成功的例子 过去对我来说，与财产甚至是 汽车。大多数人都与建筑商、木匠、 水管工，电工或观看过大量的房地产节目 电视。这种体验是一个很好的平台，可以使用并解释原因 MVC 等分离工作。我知道你可能在想 不会工作，因为它与软件不同，但请记住你是 不试图培训企业成为开发人员或参与 深入理解MVC，简单给他们解释一下分离 在生产中是必需的，这就是 MVC 结构所提供的。
举个例子来说明你如何描述这一点，我非常简短 解释了分离如何在财产中发挥作用。请记住，这是 专注于使用未开发的系统，这可能是一个完全 解释的角度不同。
查看
MVC 中的视图是表示层。 这就是最终用户 的产品将看到并与之交互。一个系统可以有多个 所有不同类型的视图，从命令行输出到 呈现的 HTML。在大多数情况下，视图不包含业务逻辑 清晰的设计。该界面适合目的，是 相互作用。因此，您可以简单地为消费者输出 HTML 与企业交互或输出 SOAP/XML 以供企业交互。两个都 在系统后面使用相同的业务逻辑，也称为 模型和控制器。
在财产世界中，您可以将视图视为内部 居民所拥有的财产或财产的外层 与。。。相互作用。内部可以定制的目的和相同 物业可以有许多不同类型的租户。例如一个 特定设计的财产可能包含住宅。 相同的内部空间可以很容易地用作办公空间，其中 虽然在同一个属性中有不同的用途。然而 属性结构相同。因此，所处的环境 用户交互不会干扰建筑物的结构。
控制器
控制器是魔法发生的地方并定义了业务 应用程序逻辑。 这可能是用户发送响应的位置 从视图上看，那么这个响应是用来处理内部的 请求的工作并处理返回给用户的响应。 以用户请求购买书籍的典型响应为例。 控制器具有用户 ID、付款详情、送货地址和 项目选择。然后通过业务处理这些元素 完成购买的逻辑。数据通过系统传递 进入模型层，最终在整个请求满足之后 业务定义、订单构建和用户 收到他们的物品。
如果我们将它与一个属性进行比较，我们可以比较一个 在线预订以打开电灯开关。租户将轻弹 就像订购一本书一样打开。开关本身是一个 视图层中的元素，它将请求发送到控制器 就像单击网站上的结帐按钮一样。业务逻辑 在这种情况下，电工安装并嵌入其中 物业设计。拨动开关，完成 电路。电力贯穿所有电线，包括保险丝盒 直通灯泡。就像用户收到一个 书，在这种情况下，租户收到光。背后的全过程 涉及电力电缆的场景是不可见的 租户。它们只是与空间内的开关交互，并从 控制器在那里处理请求。
型号
MVC中的模型是最底层，处理核心逻辑 在大多数情况下，这可以看作是 与数据源交互。在使用 MVC 的系统中，控制器 将信息传递给模型以便存储和检索 数据。继上面的控制器定义示例之后，这 是存储订单详细信息的位置。库存等附加数据 水平，本书产品的物理位置等等 都存放在这里。如果这是订购的最后一本书， 对该项目的下一个请求可能会检查它是否可用并拒绝 该订单不再可用。
继续我们打开电灯开关的例子，这个级别在 我们的结构可能是电力供应。当租户轻弹 开关，内部电路必须要求电力供电 当用户从 数据库，因为处理请求需要数据。如果住宅 没有连接到电源，它无法完成该过程。 使用 MVC 的商业利益
在您收到解释 MVC 是什么的信息后，您将 得看看能从中得到什么好处。我不去 在这里详细介绍我相信您可以申请福利 更准确地说是直接关系到你的实际情况。到 在这里仅列出基于 MVC 的系统的一些常见好处是 几个例子：
- 不同的技能级别可以在不同的系统级别上工作。例如，设计师可以在界面（视图）上工作，只需很少 开发知识和开发人员可以处理业务逻辑 （控制器）很少关注设计级别。然后他们 完成后简单地集成在一起。
- 由于上述分离项目可以更容易和更快地管理。设计者可以在设计之前启动接口 开发商，反之亦然。这个开发过程可以是并行的 与顺序相反，因此减少了开发时间。
- 使用相同的业务逻辑轻松拥有多个视图类型。
- 通过系统清除路线。您清楚地知道系统的不同级别在哪里。有了清晰的系统路线， 逻辑可以共享和改进。这增加了安全优势，因为 您清楚地知道从数据到用户的允许路径，并且可以 沿途有明确的安全检查。
- 每一层都对自己负责。 （与第 1 点有关）这意味着您可以拥有可以维护的干净文件结构 并且比紧密耦合的系统更容易和更快地管理 你可能有很多重复的逻辑。
- 拥有清晰的结构意味着开发将更加透明，这将减少开发时间， 如果应用得当，维护问题和发布周期。
【讨论】：
在这种情况下，经理头衔中的重要词是“营销”。他是一名营销经理。作为营销经理，人们所关心的问题与战略和战术有关。这两个不是一回事。战略是一个宏观的词，它包括公司如何在概念上满足客户需求以及公司如何从竞争中脱颖而出。策略通常不是软件可以向用户描绘的。另一方面，策略是公司赢得客户业务的直接方法或途径。战术往往比战略更频繁地改变，当营销经理问 MVC 能给他带来什么优势时，他可能真的在问，“你能多快改变你创造的东西，使其符合我们必须与客户打交道的新现实。”换句话说，如果奥尔巴尼下雨，你能多快将“买 1 送 1”的优惠更改为“周五买 2 送 1，如果奥尔巴尼下雨”。
营销管理是关于以美元和美分衡量的结果，而不是充斥着缺乏任何真正特异性的概念性词语的华丽和细致入微的解释。程序员可能说的每一句话对自己来说都可能有意义，但是营销经理需要知道对不断变化的客户看法或快速实施以不同方式向相同客户销售的真正可能性。他需要知道它是否会比现有方法花费更多，因为如果他在产品上多卖 100 万美元，而在软件开发上花费 125 万美元，他可能会丢掉工作。
因此，简而言之，他正在寻求灵活性和成本效益。他需要能够快速适应不断变化的条件的软件，就像他先以一种方式改变他的推销，然后再向难以说服的潜在客户改变他的推销一样，他需要知道他不必为巨额的这种灵活性的价格标签。
坦率地说，我认为如果做出这些承诺，您将无法兑现这些承诺，因为尽管从开发的角度来看 MVC 具有所有优势，但我们仍然在这里谈论软件，并且因为我们都知道，软件是一个刻板、要求苛刻的监工，它需要自己的甜蜜时间才能成熟到值得信赖的程度并消除其错误。作为程序员，我们总是在寻找软件可重用性的圣杯，当我们不断尝试一件事然后另一件事（MVC、MVP、MVVM 以及任何其他人可能想到的）时，世界其他地方只是要求有用的东西。所以祝你好运。我希望你能赢得你的案子。
【讨论】：
模型是数据访问层，它可以只是对管理数据实体关系本身的 ORM 的一些简单查询的包装器。它处理与数据源的通信、检索数据并通常将其组织到应用程序中定义的对象中。
视图只是 html 文件，其中包含一些 html 和 css 以及一些模板引擎（smarty、mako 等）代码，以按照您想要的方式显示传递给它的数据。
控制器 将它们组合在一起。对您的页面发出的请求将被路由到控制器（类）和控制器内的操作（方法）。就像任何其他应用程序一样，该操作将执行它的请求，但它仍然是控制器的一部分。
因此，控制器使用模型来查询数据（用户、内容等），然后将数据传递给视图以按照您想要的方式呈现和显示。
【讨论】：
PRESENTER。您已经描述了 Model-View-Presenter 模式。
M-V-C 把它想象成： “订单详情（包括客户和员工信息）”、“HTML/ASP 表单（显示订单详情）”和“订单详情服务类（具有 SaveOrderDetails、GetOrderDetails 的方法> 等等）。
模型（数据类，例如 OrderDetails）
控制器（服务类）
视图（ASP 页面）
【讨论】：
营销人员只会对“V”部分，即视图感兴趣。根据您的设计方式，视图只是营销人员可以修改的基本 HTML/CSS“模板”。技术上没有破坏任何东西。
理想情况下，模型（数据库）和控制器（逻辑）不应该关心视图（表示）是 XML、HTML、文本等。营销人员不应该关心模型和控制器做什么，除了请求附加功能。
更进一步的“理想”，从技术上讲，您应该能够在不触及模型或视图的情况下，将 ASP 替换为 PHP、Java、Ruby 等作为控制器。
【讨论】：
这个很简单
http://en.wikipedia.org/wiki/Model-view-controller#Pattern_description
我能想到的最好方法是，模型是数据表示，视图是向用户的呈现，而控制器是收集改变模型的用户交互的东西。
【讨论】：
对您的营销人员来说，最重要的是资金、预算、TCO ...
当您不使用 MVC 时，您通常会将设计、应用程序逻辑等全部混合在一起。
程序员必须了解 html 设计、编程等...这可能意味着您需要强大的专业人士来完成这一切。
如果你使用 MVC，一切都被分成“独立的部分”。 Html coder可以准备html层，程序员只处理应用逻辑等......
MVC 带来了更好的粒度，每个人都可以专注于他或她最擅长的事情！
听着，例如 xhtml 有效性和 css 清洁度是如此之难，以至于有很多人只关注这一点，同时考虑到很多浏览器和平台的兼容性。
通常一个人不是最好的 asp.net 程序员，xhtml 编码器合二为一；-)
【讨论】：
对于营销人员来说，解释 ASP.Net MVC 原因的最佳方式可能是扩大产品范围的能力。
通过使用 MVC，代码已经以一种方式分离，让您可以更轻松地构建一个在桌面上感觉自然的界面，然后是迎合一般移动设备用户的不同界面，以及- 迎合 iPhone 用户的不同界面，不会冒后端代码不同步和引入微妙和危害公司的错误的风险。而且，如果有一个可以成为产品的智能客户端桌面应用程序......它也可以基于相同的代码库。
模型是“盒子里的东西如何运作”。控制器是“你可以在盒子外面触摸的东西”，视图是“盒子外面的东西”......
【讨论】：
想象一个工厂的控制室，模型是机器本身，监控设备是视图，仪表板是控制器。您可以为同一台机器设置多个不同的控制室，并且一个控制室中控件的更改将反映在所有控制室的监视器上。
关键是您应该只建模一次，然后查看或控制，但最方便。
【讨论】：
你可以很容易地做到这一点，那就是如果你理解标记说话。我不知道，但我想它会变成这样......
这应该是使用。 MVC（如果操作正确）将允许您将 UI 与数据（模型）和 UI 控制（控制器）分离。这将使 UI 更加灵活，从而可以更快地更好地推销它。
【讨论】：
你必须解释 ASP.NET MVC 的好处，而不是特性
您可以控制自己的网址——这意味着网站的 SEO 会更好——这意味着你的网站在谷歌中的排名会更高
代码更简洁，意味着更容易改变，意味着你可以更快地添加功能
等等
您如何省钱、赚钱、降低风险？这就是你的老板想知道的。
【讨论】：
我不会尝试向他解释技术，我会尝试解释 MVC 架构原理的全部内容。
MVC 旨在分离关注点。干净利落。向他解释，当你构建任何东西时，你正在构建的东西可以分为两个不同的类别：业务需求是什么（领域），以及其他一切。
MVC 通过引入层来分离关注点，从而将领域与其他一切分开。 M 代表模型，这是您的域。 V 代表 View，对他来说是可见的部分，他所看到的。 C 代表 Controller，即控制域和视图之间发生的事情的部分。
【讨论】：