使用MVC将强类型视图模型注入到视图中

控制器负责更新ViewModel并将其注入View中。(用于get请求) ViewModel是DataContext和视图状态(如最后选中的项目等)的容器。 模型包含数据库实体，非常接近数据库模式，它进行查询和过滤。(我喜欢EF和LINQ) 模型还应该考虑存储库和或将结果投影到强类型(EF有一个很好的方法……EF.Database。选择(querystring, parms)直接ADO访问注入查询和返回强类型。这解决了EF是缓慢的参数。EF并不慢! ViewModel获取数据并执行业务规则和验证 post后面的控制器将调用ViewModel post方法并等待结果。 控制器会将最新更新的视图模型注入到视图中。视图只使用强类型绑定。 视图仅仅呈现数据，并将事件发送回控制器。(参见下面的例子) MVC拦截入站请求，并将其路由到具有强数据类型的适当控制器

在这个模型中，不再有HTTP级别的与请求或响应对象的接触，因为MSFT的MVC机器对我们隐藏了它。

澄清上文第6项(应要求)…

假设ViewModel是这样的:

public class myViewModel{
     public string SelectedValue {get;set;}
public void Post(){
    //due to MVC model binding the SelectedValue string above will be set by MVC model binding on post back.
    //this allows you to do something with it.
    DoSomeThingWith(SelectedValue);
    SelectedValue = "Thanks for update!";
 }
}

这篇文章的控制器方法看起来像这样(见下文)，注意mvm的实例是由MVC绑定机制自动实例化的。因此，您永远不必下拉到查询字符串层!这是MVC基于查询字符串为您实例化ViewModel !

[HTTPPOST]   
public ActionResult MyPostBackMethod (myViewModel mvm){
         if (ModelState.IsValid)
        {
               // Immediately call the only method needed in VM...
               mvm.Post()
        }
      return View(mvm);
}

注意，为了让上面的actionmethod像你想要的那样工作，你必须定义一个空CTOR来初始化post中没有返回的东西。回发也必须回发那些发生变化的名称/值对。如果缺少名称/值对，MVC绑定引擎就会做正确的事情，而这根本不是什么!如果发生这种情况，你可能会发现自己说“我正在丢失回post的数据”…

这种模式的优点是ViewModel做了所有“杂乱”的工作，接口到模型/业务逻辑，控制器只是一个路由器。这是SOC在起作用。

据我所知,MVVM映射到MVC的MV——也就是说,在传统的MVC模式V不沟通直接与M .第二版本的MVC,之间有一个直接联系M和诉MVVM似乎把所有任务相关的M和V交流,和夫妻分离它的c .实际上,还有大范围应用程序工作流程(或实现的使用场景)中没有完全占MVVM。这就是控制器的作用。通过从控制器中删除这些较低级别的方面，它们更干净，更容易修改应用程序的使用场景和业务逻辑，也使控制器更具可重用性。

MVVM模型-视图视图模型类似于MVC，模型-视图控制器

控制器被替换为ViewModel。ViewModel位于UI层下面。ViewModel公开视图所需的数据和命令对象。你可以把它想象成一个容器对象视图从它那里获取数据和动作。ViewModel从模型中提取数据。

Russel East写了一篇博客，详细讨论了为什么MVVM不同于MVC

MVVM将视图模型添加到混合中。这很重要，因为它允许您大量使用WPF的绑定方法，而无需将所有特定于UI的部分放在常规模型中。

我可能是错的，但是我不确定MVVM真的强迫控制器混合。我发现这个概念更符合:http://martinfowler.com/eaaDev/PresentationModel.html。我认为人们选择将其与MVC结合起来，而不是将其内置到模式中。

MVC/MVVM不是一个非此即彼的选择。

这两种模式以不同的方式出现在ASP。Net和Silverlight/WPF开发。

ASP。Net, MVVM用于视图内的双向绑定数据。这通常是一个客户端实现(例如使用Knockout.js)。另一方面，MVC是一种在服务器端分离关注点的方法。

对于Silverlight和WPF来说，MVVM模式包含的内容更广泛，可以作为MVC(或其他将软件组织成独立职责的模式)的替代品。这种模式中经常出现的一个假设是，ViewModel简单地取代了MVC中的控制器(就好像你可以用VM代替C的首字母缩写一样，一切都可以原谅)……

ViewModel并不一定会取代对独立控制器的需求。

问题是:为了能够独立测试*，特别是在需要时可重用，视图模型不知道是什么视图显示了它，但更重要的是不知道它的数据来自哪里。

*注意:在实践中，控制器从ViewModel中删除了大部分需要单元测试的逻辑。VM就变成了一个不需要测试的容器，只需要很少的测试。这是一件好事，因为VM只是设计师和编码器之间的桥梁，所以应该保持简单。

即使在MVVM中，控制器也通常包含所有的处理逻辑，并决定使用哪个视图模型在哪个视图中显示哪些数据。

到目前为止，我们已经看到ViewModel模式的主要好处是从XAML后台代码中删除代码，从而使XAML编辑成为一个更加独立的任务。当需要时，我们仍然创建控制器来控制(没有双关语)应用程序的整体逻辑。

我们遵循的基本MVCVM指南是:

视图显示数据的特定形状。他们不知道数据从何而来。 ViewModels保存着特定形状的数据和命令，它们不知道数据或代码来自哪里，也不知道它是如何显示的。 模型保存实际数据(各种上下文、存储或其他方法) 控制器监听并发布事件。控制器提供了控制在哪里看到什么数据的逻辑。控制器为ViewModel提供命令代码，以便ViewModel实际上是可重用的。

我们还注意到，Sculpture代码生成框架实现了MVVM和类似于Prism的模式，它还大量使用控制器来分离所有用例逻辑。

不要认为控制器已经被视图模型淘汰了。

我已经开始了一个关于这个主题的博客，当我可以的时候，我会添加进去(只有当主机丢失时存档)。将MVCVM与通用导航系统相结合存在一些问题，因为大多数导航系统只使用视图和vm，但我将在后面的文章中讨论这个问题。

使用MVCVM模型的另一个好处是，在应用程序的生命周期中，只有控制器对象需要存在于内存中，并且控制器主要包含代码和少量的状态数据(即很小的内存开销)。与需要保留视图模型的解决方案相比，这大大减少了应用程序的内存密集型，并且非常适合某些类型的移动开发(例如使用Silverlight/Prism/MEF的Windows mobile)。这当然取决于应用程序的类型，因为您可能仍然需要保留偶尔缓存的虚拟机来响应。

注意:这篇文章已经编辑了很多次，并没有特别针对所提出的狭窄问题，所以我更新了第一部分，现在也包括了这个问题。在下面的评论中，大部分讨论只与ASP有关。而不是更广阔的图景。本文旨在介绍MVVM在Silverlight、WPF和ASP中的广泛使用。Net，并试图阻止人们用ViewModels替换控制器。

微软在这里提供了Windows环境中MVVM模式的解释。

这里有一个关键的部分:

在模型-视图-视图模型设计模式中，应用程序由以下部分组成 三个一般组成部分。 模型:这表示应用程序使用的数据模型。例如，在图片共享应用程序中，此层可能表示 设备上可用的图片集和用于读取和的API 写入图片库。 视图:应用通常由多个UI页面组成。显示给用户的每个页面都是MVVM术语中的一个视图。观点是 用于定义和设置用户所看到内容样式的XAML代码。的数据 从模型显示到用户，这是工作的 的当前状态为UI提供此数据 例如，在一个图片共享应用中，视图就是UI 向用户显示设备上的相册列表，其中的图片 一个相册，或者另一个向用户显示特定信息的相册 图片。 ViewModel: ViewModel将数据模型或简单的模型绑定到应用程序的UI或视图上 哪一个来管理模型中的数据并将数据作为一个集合公开 XAML UI或视图可以绑定到的属性。例如, 在图片共享应用中，ViewModel会显示一个相册列表， 并且为每个相册公开一个图片列表。UI是不可知论的 图片从何而来，如何获取。它只是 知道ViewModel所显示的一组图片，并显示它们 对用户。