视图模型日常只含有领域模型的一个子集,而且只包含界面上所急需的属性。其余,视图模型可能是一个世界模型树的扁平版本,例如,一个Customer实体有一个Address,而那又是一个完好无损,它含有街道地址,邮编,国家等。一个Customer
视图模型用于展现数据,将地点数据拉平填充到视图模型类里。

   
接纳哪一种 Domain
Model 类型取决于你的应用环境。假如你正在创制的是一个至极简单的表单处理
web 应用,没必要建立 Rich Domain
Model。可是,倘诺你正在编制一个市值数百万的商家内联网架构的主导库,那么拼命付出一个
Rich Domain Model
就是值得的,它可以为您提供一个准儿表明业务过程的阳台,并可以让您急迅传输数据。

   
直接将你的园地模型作为Conroller上的拍卖参数面临着平安风险,因为Controller或者Model
binder必须保证属性验证和用户不可能修改她要好不可能改改的习性(例如,用户手动更新了一个掩蔽的输入值,或扩展一个附加的属性值,而以此并不是界面上的元素,但却刚刚领域模型实体的性能,这种高风险叫做“over-posting”),即使对当下版本的世界模型做了科学的验证,领域模型未来说不定做了改观修改,并从未现身编译错误或者警告,可能导致新的高风险。
   
咱们理应避免选用前几种办法将世界模型转换成视图模型,推荐应用第两种艺术,定义单独的视图模型类。做这种领域模型到视图模型的转换工作是一种重复性的劳作,已经有多少个工具得以扶持您来完成这项工作。最常用的一个工具就是.NET
社区的开源项目AutoMapper。

   
此外假使一个View需要同时处理多少个领域模型,View
Model就是那一个Domain
Model的总额。领域模型和视图模型之间有许多相似的地方,大家平常干脆就把Domain
Model当作View Model来利用了。
   
上边钻探了世界模型和视图模型的相似性,我们来看望都有三种办法把世界模型转换为视图模型,平日有3种艺术:

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

   
这几个实体有成千上万性能,有同一或接近的称呼,你可以很容易地映射领域实体对应视图模型中的一个特性。不过,这个相似的性质也可能略有不同,例如类型或者格式。例如,用户填写的用户界面的一个性质,他在视图模型里也许是一个“Nullable”的。

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

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

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

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

    DomainModel != ViewModel

    Domain
Model
是一个对象层,是对切实世界逻辑、数据和您应用程序所处理的问题的虚幻。

    Martin福勒 在 PoEAA 中还要省略介绍了二种 Domain Model。而 Eric(Eric) 埃文思(Evans) 的
Domain Driven Design 一书,则统统专注于 Rich Domain Model
的推行应用和支出进程。

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

 (私家知道:针对域模型与视图模型,有时候需要看具体的工作场景,一般情状下可以依据上述将DomainModel和ViewModel举行多少映射,以避免有些安全性问题;不过也足以将DomainModel当成ViewModel来采用也是足以的,通过在系统贯彻、业务逻辑操作和判断上是可以确保工作安全性的。就是前者也要举行判断以保证安全性。所以,仍然看具体事务体系的采用条件与要求来控制采用哪一类方法来促成。

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

    Model
包含了你的应用逻辑和数量,在您的应用程序中,它很可能是至关首要的值驱动器。Model
没有其余与表现层相关的特征,而且也和 HTTP
请求处理职责中完全无关。

   
我们不提出直接把世界模型实体透露给视图,因为有成百上千一线之处,可能导致你混合业务和表示层的逻辑,无论是领域实体的性质突显依旧政工的辨证规则,这都是应用程序处理的两样方面。

   
与此外设计形式不同,MVC
情势并没有平素反映一个您可知编写或配备的类协会。相反,MVC
更像一个定义上的引导标准或范型。概念上的 MVC 情势被描述为两个对象 ——
Model、View 和 Controller —— 之间的关联。由于 View 和 Controller
都足以从 Model 请求数据,所以 Controller 和 View 都依靠
Model。任何输入都经过 Controller 进入你的系统,然后 Controller 采取一个
View 来暴发结果。

   
另一方面,领域实体可能需要一个由此证实的法定的值,所以需要一个在用户界面的小圈子模型之间的变换。另一个例证是,用户界面可能会来得一个滑块,用于用户选用多少天之后提交他的订单。在这种情状下,视图模型可能利用一个平头特性来代表,领域模型平常是一个日期值。

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

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

   
许多的MVC模式的兑现也都施用一个View Model或Application
Model的定义,Controller是关系的媒婆,架起世界模型和用户界面之间的桥梁,属于表现层。为了View的简单性,Controller负责处理如故将世界模型转换成一个View
Model,这一般称为数据传输对象(DTO)

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

相关文章

网站地图xml地图