天地模型

   
Model-View-Controller(模型-视图-控制器,MVC)格局将你的软件协会并分解成多少个精光不同的角色:

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

   
与其他设计格局不同,MVC
格局并不曾一向反映一个你可以编写或安排的类社团。相反,MVC
更像一个定义上的指点原则或范型。概念上的 MVC 格局被描述为五个对象 ——
Model、View 和 Controller —— 之间的涉嫌。由于 View 和 Controller
都足以从 Model 请求数据,所以 Controller 和 View 都依靠
Model。任何输入都经过 Controller 进入你的系统,然后 Controller 采纳一个
View 来发出结果。

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

    Domain
Model
是一个对象层,是对实际世界逻辑、数据和您应用程序所拍卖的问题的空洞。

    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
    往往是柔性的,精心测试过的,不断重构的,而且与它们所发挥的小圈子所需的作业逻辑严密耦合。

   
采取哪一类 Domain
Model 类型取决于你的应用环境。假诺您正在成立的是一个分外简单的表单处理
web 应用,没必要建立 Rich Domain
Model。可是,如果您正在编纂一个市值数百万的营业所内联网架构的中坚库,那么拼命开发一个
Rich Domain Model
就是值得的,它可以为你提供一个准确表明业务经过的平台,并得以让你快速传输数据。

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

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

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

    DomainModel != ViewModel

   
DomainModel代表着相应的域,但ViewModel却是为View的需要而创建。那两者之间或许(一般意况下都)是见仁见智的,其它DomainModel是数量增长行为的组合体,是由复杂的变量类型组成的同时具有层次。而ViewModel只是由一些String等简易变量类型组成。如若想移除冗余并且容易导致出错的ORM代码,可以选拔AutoMapper.倘使想要了然更多。

   
这就是说领域模型(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