天地模型

 玩具模型     |      2019-12-19 11:20

    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 包含了您的应用逻辑和数据,在你的应用程序中,它很可能是任重(Ren Zhong卡塔尔(قطر‎而道远的值驱动器。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来利用也是能够的,通过在系统落成、业务逻辑操作和剖断上是足以确认保证工作安全性的。正是前边二个也要拓宽推断以保障安全性。所以,如故看现实业务系统的行使境遇与须求来调整选择哪个种类方式来促成。

 

作品转发自: