都足以从 Model 请求数据,概念上的 MVC 格局被描述为五个目的 ——

   
Model-View-Controller(模型-视图-控制器,MVC)形式将您的软件协会并分解成多少个完全不同的角色:

Model-View-Controller(模型-视图-控制器,MVC)
情势将您的软件社团并分解成多少个精光不同的角色:

  • Model
    封装了您的行使数据、应用流程和工作逻辑。
  • View
    从 Model 获取数据并格式化数据以开展体现。
  • Controller
    控制程序流程,接收输入,并把它们传递给 Model 和 View。
  • Model 封装了您的运用数据、应用流程和业务逻辑。

  • View 从 Model 获取数据并格式化数据以拓展展示。

  • Controller 控制程序流程,接收输入,并把它们传递给 Model 和 View。

   
与其它设计形式不同,MVC
格局并从未直接突显一个你可知编写或部署的类协会。相反,MVC
更像一个定义上的指点规范或范型。概念上的 MVC 形式被描述为五个目的 ——
Model、View 和 Controller —— 之间的涉及。由于 View 和 Controller
都得以从 Model 请求数据,所以 Controller 和 View 都凭借
Model。任何输入都由此 Controller 进入你的体系,然后 Controller 选用一个
View 来暴发结果。

与此外设计模式不同,MVC
形式并从未一向反映一个您可知编写或部署的类社团。相反,MVC
更像一个概念上的指引规范或范型。概念上的 MVC 形式被描述为多少个目的 ——
Model、View 和 Controller —— 之间的涉及。由于 View 和 Controller
都得以从 Model 请求数据,所以 Controller 和 View 都凭借
Model。任何输入都通过 Controller 进入你的系统,然后 Controller 采纳一个
View 来发生结果。

    Model
包含了您的应用逻辑和数目,在你的应用程序中,它很可能是重点的值驱动器。Model
没有其它与表现层相关的风味,而且也和 HTTP
请求处理职责中全然无关。

Model
包含了你的应用逻辑和多少,在您的应用程序中,它很可能是至关重要的值驱动器。Model
没有任何与表现层相关的风味,而且也和 HTTP 请求处理职责中全然无关。

    Domain
Model
是一个对象层,是对具体世界逻辑、数据和您应用程序所拍卖的题目的抽象。

Domain Model
是一个目的层,是对实际世界逻辑、数据和你应用程序所处理的题材的架空。Domain
Model 可分为两大类:Simple Domain Model 和 Rich Domain Model。

    Domain
Model 可分为两大类:Simple Domain Model 和 Rich Domain Model。

Simple Domain Model
往往是事情对象和数量库表之间一对一的通信。你早已见过的三种模式 —— Active
Record、Table Data Gateway,以及 Data
Mapper,所有这个与数据库相关的设计形式 ——
可以帮衬您把与数据库相关的逻辑协会成一个 Domain Model。

  • Simple Domain Model
    往往是事情对象和数据库表之间一对一的通信。你早就见过的两种形式 ——
    Active Record、Table Data Gateway,以及 Data
    Mapper,所有这个与数据库相关的设计形式 ——
    能够扶助您把与数据库相关的逻辑社团成一个 Domain
    Model。
  • Rich Domain
    Model 包含复杂的,使用持续机制紧密联系在一起的靶子网络,在本书和 GoF
    一书中介绍的重重情势起着杠杆功效。Rich Domain Models
    往往是柔性的,精心测试过的,不断重构的,而且与它们所发布的圈子所需的事情逻辑严峻耦合。

Rich Domain Model
包含复杂的,使用持续机制紧密联系在一起的对象网络,在本书和 GoF
一书中介绍的大队人马格局起着杠杆效能。Rich Domain Models
往往是柔性的,精心测试过的,不断重构的,而且与它们所表达的领域所需的工作逻辑严峻耦合。

   
选拔哪个种类 Domain
Model 类型取决于你的应用环境。假使您正在建立的是一个非凡简单的表单处理
web 应用,没必要建立 Rich Domain
Model。但是,假如你正在编写一个市值数百万的商店内联网架构的主干库,那么拼命付出一个
Rich Domain Model
就是值得的,它可以为您提供一个准确表明业务经过的平台,并得以让你快捷传输数据。

动用哪一类 Domain Model
类型取决于你的应用环境。假若您正在创制的是一个十分简单的表单处理 web
应用,没必要建立 Rich Domain
Model。不过,假诺你正在编写一个价值数百万的商号内联网架构的中央库,那么拼命付出一个
Rich Domain Model
就是值得的,它可以为您提供一个纯正表明业务过程的阳台,并可以让您快捷传输数据。

    马丁福勒 在 PoEAA 中并且概括介绍了三种 Domain Model。而 Eric Evans 的
Domain Driven Design 一书,则完全专注于 Rich Domain Model
的进行应用和开发进程。

马丁 Fowler 在 PoEAA 中而且省略介绍了二种 Domain Model。而 埃里克(Eric) Evans的 Domain Driven Design 一书,则一心专注于 Rich Domain Model
的实践应用和开发过程。

    View
用于拍卖所有表现层方面的题目。View 从 Model
获取数据,并得以把它格式化成用于 web 页的 HTML,用于 web 服务的
XML,或用于 email 的文件。

View 用于拍卖所有表现层方面的题目。View 从 Model
获取数据,并能够把它格式化成用于 web 页的 HTML,用于 web 服务的
XML,或用于 email 的文本。

   
许多的MVC格局的兑现也都采取一个View Model或Application
Model的定义,Controller是交流的红娘,架起世界模型和用户界面之间的桥梁,属于表现层。为了View的简单性,Controller负责处理仍旧将世界模型转换成一个View
Model,这一般称为数据传输对象(DTO)

洋洋的MVC形式的兑现也都选择一个View Model或Application
Model的定义,Controller是关联的媒介,架起世界模型和用户界面之间的大桥,属于表现层。为了View的简单性,Controller负责处理或者将世界模型转换成一个View
Model,这平时号称数据传输对象(DTO)。

    DomainModel != ViewModel

<译>12个asp.net
MVC最佳实践
针对Model的一流实践有这样一段:

   
DomainModel代表着相应的域,但ViewModel却是为View的急需而创办。这两者之间或许(一般景色下都)是例外的,其它DomainModel是数额增长行为的组合体,是由复杂的变量类型组成的同时存有层次。而ViewModel只是由局部String等简便变量类型组成。如若想移除冗余并且容易导致出错的ORM代码,可以利用AutoMapper.倘若想要领悟更多。

7–DomainModel != ViewModel

 *DomainModel代表着相应的域,但ViewModel却是为View的需要而创办。这两者之间或许(一般情况下都)是见仁见智的,此外DomainModel是数据增长行为的组合体,是由复杂的变量类型组成的还要拥有层次。而ViewModel只是由局部String等简易变量类型组成。倘诺想移除冗余并且容易造成出错的ORM代码,能够动用[AutoMapper](http://www.codeplex.com/AutoMapper).尽管想要了然更多,我推荐阅读:[ASP.NET
MVC View Model
Patterns](http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx).*

那么领域模型(Domain Model )和视图模型(View Model)有哪些不同呢?

在ASP.NET MVC的应用程序中时时可以可以观望View
Model,平常大家都觉得世界模型和视图模型是同一个事物。这特别是把世界模型包含在数码传输对象DTO里的时候,例如使用Entity
Framework之类的ORM工具生成的实业。在这种场馆下,领域模型和视图模型包含的实体卓殊相似,都是一些粗略的CRUD操作。

这么些实体有为数不少性质,有相同或近乎的名号,你可以很容易地映射领域实体对应视图模型中的一个属性。可是,这一个相似的特性也说不定略有不同,例如类型或者格式。例如,用户填写的用户界面的一个特性,他在视图模型里可能是一个“Nullable”的。另一方面,领域实体可能需要一个通过验证的法定的值,所以需要一个在用户界面的小圈子模型之间的转换。另一个事例是,用户界面可能会显示一个滑块,用于用户采用多少天过后提交他的订单。在这种情景下,视图模型可能拔取一个平头属性来表示,领域模型平时是一个日期值。

视图模型常常只包含领域模型的一个子集,而且只含有界面上所需要的习性。另外,视图模型可能是一个天地模型树的扁平版本,例如,一个Customer实体有一个Address,而这又是一个一体化,它涵盖街道地址,邮编,国家等。一个Customer
视图模型用于展现数据,将地点数据拉平填充到视图模型类里。

其余要是一个View需要同时处理多少个领域模型,View Model就是这一个Domain
Model的总和。领域模型和视图模型之间有诸多貌似的地点,大家平时干脆就把Domain
Model当作View Model来使用了。

地点商量了世界模型和视图模型的相似性,我们来探望都有三种方法把世界模型转换为视图模型,日常有3种艺术:

  1. 把世界模型当作视图模型来用,也就是圈子模型就是视图模型,大部分都是如此用的。
  2. 视图模型里面富含一个世界模型,定义一个视图模型,里面包含了一个领域模型,通过性能模式开展访问。
  3. 将世界模型映射到视图模型,领域模型并不曾一直照射到视图模型,需要处理这种映射关系。

咱俩不提出直接把世界模型实体表露给视图,因为有为数不少微小之处,可能引致您混合业务和表示层的逻辑,无论是领域实体的性质显示如故工作的印证规则,这都是应用程序处理的不比方面。直接将你的世界模型作为Conroller上的处理参数面临着平安风险,因为Controller或者Model
binder必须保证属性验证和用户不可以改改她自己不可以改改的性质(例如,用户手动更新了一个潜伏的输入值,或扩充一个额外的属性值,而这些并不是界面上的要素,但却恰恰领域模型实体的性能,那种高风险叫做“over-posting”),即便对最近版本的领域模型做了不错的辨证,领域模型以后或者做了变动修改,并从未出现编译错误或者警示,可能导致新的风险。

我们应有制止使用前两种艺术将世界模型转换成视图模型,推荐应用第三种情势,定义单独的视图模型类。做这种领域模型到视图模型的更换工作是一种重复性的做事,已经有多少个工具得以扶持你来形成那项工作。最常用的一个工具就是.NET
社区的开源项目AutoMapper

 

哪些行使AutoMapper可以参照下边的两篇著作介绍:

AutoMapper Formatters are Cool – ASP.NET MVC
Style

AutoMapper in NerdDinner

   
这就是说领域模型(Domain Model
)和视图模型(View Model)有什么两样啊?

   
在ASP.NET MVC的应用程序中时时能够可以见到View
Model,平时我们都觉得世界模型和视图模型是同一个东西。这特别是把世界模型包含在数额传输对象DTO里的时候,例如利用Entity
Framework之类的ORM工具生成的实业。在这种气象下,领域模型和视图模型包含的实业非凡相像,都是一些粗略的CRUD操作。

   
这些实体有许多特性,有一致或看似的称谓,你可以很容易地映射领域实体对应视图模型中的一个性能。但是,那些相似的性能也说不定略有不同,例如类型或者格式。例如,用户填写的用户界面的一个属性,他在视图模型里或者是一个“Nullable”的。

   
另一方面,领域实体可能需要一个通过验证的官方的值,所以需要一个在用户界面的领域模型之间的转换。另一个事例是,用户界面可能会体现一个滑块,用于用户挑选多少天过后提交他的订单。在这种场合下,视图模型可能接纳一个平头属性来表示,领域模型平日是一个日期值。

   
视图模型平日只含有领域模型的一个子集,而且只包含界面上所急需的性质。此外,视图模型可能是一个领域模型树的扁平版本,例如,一个Customer实体有一个Address,而这又是一个总体,它富含街道地址,邮编,国家等。一个Customer
视图模型用于体现数据,将地方数据拉平填充到视图模型类里。

   
其它借使一个View需要同时处理多少个世界模型,View
Model就是这么些Domain
Model的总额。领域模型和视图模型之间有过多形似的地点,我们通常干脆就把Domain
Model当作View Model来行使了。
   
下边商量了世界模型和视图模型的相似性,我们来探视都有两种艺术把世界模型转换为视图模型,通常有3种方法:

  • 把世界模型当作视图模型来用,也就是小圈子模型就是视图模型,大部分都是这样用的。
  • 视图模型里面含有一个天地模型,定义一个视图模型,里面富含了一个世界模型,通过性能模式举行走访。
  • 将世界模型映射到视图模型,领域模型并不曾从来照射到视图模型,需要处理这种映射关系。

   
我们不提议间接把世界模型实体表露给视图,因为有过多分寸之处,可能引致您混合业务和表示层的逻辑,无论是领域实体的性能展现仍然工作的辨证规则,这都是应用程序处理的两样方面。

   
直接将您的小圈子模型作为Conroller上的处理参数面临着安全风险,因为Controller或者Model
binder必须保证属性验证和用户不可以改改她自己无法修改的习性(例如,用户手动更新了一个隐身的输入值,或扩展一个额外的属性值,而这么些并不是界面上的要素,但却刚刚领域模型实体的性能,这种风险叫做“over-posting”),即便对如今版本的天地模型做了科学的辨证,领域模型往后或者做了变动修改,并没有出现编译错误或者警示,可能引致新的风险。
   
咱俩理应制止采取前二种方法将世界模型转换成视图模型,推荐应用第二种办法,定义单独的视图模型类。做这种领域模型到视图模型的变换工作是一种重复性的行事,已经有多少个工具得以襄助您来完成这项工作。最常用的一个工具就是.NET
社区的开源项目AutoMapper。

 (民用通晓:针对域模型与视图模型,有时候需要看现实的事情场景,一般情状下得以遵照上述将DomainModel和ViewModel举行数据映射,以制止有些安全性问题;但是也可以将DomainModel当成ViewModel来拔取也是可以的,通过在系统实现、业务逻辑操作和判断上是足以保证工作安全性的。就是前者也要开展判定以保险安全性。所以,依然看现实业务系统的施用环境与要求来支配运用哪类办法来落实。

 

小说转载自:http://www.cnblogs.com/shanyou/archive/2010/04/03/1703501.html

相关文章