weixin_34143774
weixin_34143774

MVC ViewModel

ViewModel这个概念不只是在在MVC模式中有，你会在很多关于MVC、MVP、MVVM的文章中见到这个说法，并且这个概念在任何技术中都有可能提到，比如ASP.NET, Silverlight, WPF, or MVC... 现在我们来讨论如何在MVC中使用它。

 

ASP.NET MVC ViewModel 是什么？

在一般的情况下，我们向View中传递数据的时候，都是一个Model，当有一些额外的数据的时候，我们会使用viewbag等来进行，但是我们可以使用ViewModel将这些整合在一起也就是说：ASP.NET MVC 中的ViewModel允许你将一个或者多个data model和资源整合到一个对象中去，以此使View使用model的时候得到优化，下面的图说明了ViewModel的概念：

个人认为：viewModel 就是多个Model相结合，然后渲染同一个View

使用ViewModel的目的就是让View单个的对象来进行渲染，另一方面可以减少UI展示的逻辑代码，这个是很有必要的，也就是说View唯一的任务就是渲染单个的ViewModel对象，为了让concerns之间有一个清晰的分离，解耦意味着你的程序被设计的更好，所以我们要将对数据处理的代码放在它应该在的位置，远离View、controller。

创建个ViewModel                                                                          

尽管Viewmodel包含了几个实体，但是它任然只是一个类，没有什么特别的，放置它的位置可以是：

1、一个叫做ViewModels的文件夹中，这个文件夹可以放在项目的根目录中；

2、作为一个dll，我们从MVC项目中引用它；

3、放在一个分开的项目中的service layer；

而第一种方式无疑是最简单的一种，我们只需要创建一个文件夹，然后创建一个类就行了。

为了创建一个CustomerViewModel，我们要将Customer和StateDirctionary类型作为属性，来共同组建一个CustomerViewModel类，代码如下：

复制代码
public class CustomerViewModel 
{ 
    public Customer Customer { get; set; } 
    public StatesDictionary States { get; set; } 
    public CustomerViewModel(Customer customer) 
    { 
        Customer = customer; 
        States = new StatesDictionary(); 
    } 
} 
复制代码

 

将ViewModel发送到Veiw                                                               

当然我们是从Controller开始的，将ViewModel发送到View和我们将普通的model发送到View的做法是一样的，因为ViewModel只是一个类，View不知道也不会在意model或者viewModel是从哪里来的，你可以在controller中创建一个ViewModel的实例，为了保证controller的整洁，没有额外的代码，在Controller中需要做的只是取得model或者ViewModel的值，没有其他的：

复制代码
public ActionResult Edit(int id) 
{ 
     Customer customer = context.Customers.Single(x => x.Id == id); 
     var customerViewModel = new CustomerViewModel(customer); 
     return View(customerViewModel); 
} 
复制代码

 

 

然后就是view来渲染ViewModel                                                       

为了让View知道我们传过去的是哪一个对象，我们需要将@model关键字指向ViewModel，就像你在指定一个一般的model一样。

@model FourthCoffee.Web.ViewModels.CustomerViewModel

 

调用数据的代码：

复制代码
   @Html.LabelFor(model => model.Customer.FirstName) 

   @Html.EditorFor(model => model.Customer.FirstName) 
   @Html.ValidationMessageFor(model => model.Customer.FirstName) 

@* ...View code continues rendering properties... 
复制代码

使用ViewModel的小建议：                                                              

1、因为使用ViewModel时需要手动的进行映射，但是当ViewModel很复杂的时候，这个将会变得比较困难，这个时候，我们就可以是使用AutoMapper来简化简化工作，AutoMapper会让你顺畅的在ViewModel和models之间创建映射，除此之外还有：POCO Generator、EF POCO Templates

2、只把你在View上用来渲染的属性放到ViewModel中

3、用View来指导ViewModel属性的创建，这样才能更好的渲染和维护

下面是英文文档：

 

The concept of the ViewModel isn’t just for ASP.NET MVC, as you’ll see references to ViewModels throughout the web in articles and blog posts about the MVC, MVP, and MVVM patterns. Those posts and articles can center around any number of technologies such as ASP.NET, Silverlight, WPF, or MVC… This post will investigate ViewModels as they apply to the world of ASP.NET MVC.

What is an ASP.NET MVC ViewModel?

In ASP.NET MVC, ViewModels allow you to shape multiple entities from one or more data models or sources into a single object, optimized for consumption and rendering by the view. The below image illustrates the concept of a ViewModel:

 

The purpose of a ViewModel is for the view to have a single object to render, alleviating the need for UI logic code in the view that would otherwise be necessary. This means the only responsibility, or concern, of the view is to render that single ViewModel object, aiding in a cleaner separation of concerns (SoC). Concerns are distinct aspects of the application that have a particular purpose (i.e., concern), and keeping these aspects apart means your application is more organized, and the code more focused. Putting data manipulation code in its own location away from the view and controller, enforces SoC.

Using ViewModels in MVC for finer granularity and better SoC leads to more easily maintainable and testable code. Remember, unit testing is about testing small units.

Along with better coding practices, there are many business reasons demonstrating why you might consider using ViewModels:

  • Incorporating dropdown lists of lookup data into a related entity
  • Master-detail records view
  • Pagination: combining actual data and paging information
  • Components like a shopping cart or user profile widget
  • Dashboards, with multiple sources of disparate data
  • Reports, often with aggregate data

The above scenarios are common to a wide variety of applications, and deal with more complex data than basic CRUD forms-over-data page (e.g., a simple 1:1 mapping to the db table). For example, providing a list of states, and ensuring that the state that matches the state of current customer, means that you need to either provide two sets of data or a single set of customer/state data combined, as shown in the image below.

 

Some scenarios such as a lookup table representing states in the USA, could easily work with either ViewModels or a ViewBag/ViewData object, so there is some potential overlap at times. It’s up to the application architects and developers to decide what works best with their exact use case.

Creating a ViewModel

Although a ViewModel consists of multiple entities, at its core a ViewModel is still just a class – and one that doesn’t even inherit from anything special, as many MVC classes do.

Physically, ViewModels can exist in different locations, listed below:

  • In a folder called ViewModels that resides in the root of the project. (small apps)
  • As a .dll referenced from the MVC project (any size app)
  • In a separate project(s) as a service layer, for large applications that generate view/content specific data. (enterprise apps)

Since a ViewModel is just a class, the easiest way to get started using one is to create a new folder named ViewModels and add a new code file to it.

To create the CustomerViewModel ViewModel, add the Customer and StatesDictionary types as properties to form one CustomerViewModel class. In the example below, the CustomerViewModel class contains the newly defined properties.

public class CustomerViewModel

 

{

 

    public Customer Customer { get; set; }

 

    public StatesDictionary States { get; set; }

 

    public CustomerViewModel(Customer customer)

 

    {

 

        Customer = customer;

 

        States = new StatesDictionary();

 

    }

 

}

 

Generally, ViewModels contain the word “ViewModel” as part of its name; however, the conventions at work here are for consistency in code readability, since other classes in MVC state their intents in their names as well (e.g., names of controllers, action methods, etc…use conventions in their names).

The StatesDictionary class is a simple Dictionary object containing two type parameters of type string. The class also contains the definitions for all the members in the Dictionary (i.e., the state data). The only property in the StatesDictionary class is the StateSelectList, which is an object that Html Helpers use with to render an HTML