领域模型

   
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
便是值得的,它可认为您提供八个正确表达业务进程的阳台,并能够让您火速传输数据。

    MartinFowler 在 PoEAA 中并且总结介绍了三种 Domain Model。而 Eric 埃文思 的
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

admin

网站地图xml地图