NET网页编程之ASP.NET MVC中利用View Model分别范畴模子

是不是实质都是API？有的好像不只是API那么简单的，有的也是一种框架就像MFC一样。有的还是一种思想（就是做软件的思想）（好像很深奥，其实我也不懂^_^）<p>MVC架构形式是最近几年来编程天下里最长被说起的形式之一，ModelViewController(模子-视图-把持器，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哀求处置职责中完整有关。DomainModel是一个工具层，是对实际天下逻辑、数据和你使用程序所处置的成绩的笼统。DomainModel可分为两年夜类：SimpleDomainModel和RichDomainModel。
SimpleDomainModel常常是营业工具和数据库表之间一对一的通讯。你已见过的几种形式——ActiveRecord、TableDataGateway，和DataMapper，一切这些与数据库相干的计划形式——能够匡助你把与数据库相干的逻辑构造成一个DomainModel。
RichDomainModel包括庞大的，利用承继机制严密接洽在一同的工具收集，在本书和GoF一书中先容的浩瀚形式起着杠杆感化。RichDomainModels常常是柔性的，经心测试过的，不休重构的，并且与它们所表达的范畴所需的营业逻辑严密耦合。
接纳哪一种DomainModel范例取决于你的使用情况。假如你正在创建的是一个十分复杂的表单处置web使用，没需要创建RichDomainModel。但是，假如你正在编写一个代价数百万的企业内联网架构的中心库，那末勉力开辟一个RichDomainModel就是值得的，它能够为你供应一个正确表达营业历程的平台，并可让你疾速传输数据。
MartinFowler在PoEAA中同时扼要先容了两种DomainModel。而EricEvans的DomainDrivenDesign一书，则完整专注于RichDomainModel的理论使用和开辟历程。View用于处置一切体现层方面的成绩。View从Model猎取数据，并能够把它格局化成用于web页的HTML，用于web服务的XML，或用于email的文本。
很多的MVC形式的完成也都利用一个ViewModel或ApplicationModel的观点，Controller是相同的前言，架起范畴模子和用户界面之间的桥梁，属于体现层。为了View的复杂性，Controller卖力处置大概将范畴模子转换成一个ViewModel，这一般叫做数据传输工具（DTO）。12个ASP.NETMVC最好理论针对Model的最好理论有这么一段：
7&ndash;DomainModel!=ViewModel
DomainModel代表着响应的域，但ViewModel倒是为View的必要而创立。这二者之间也许(一样平常情形下都)是分歧的，别的DomainModel是数据加下行为的组合体，是由庞大的变量范例构成的而且具有条理。而ViewModel只是由一些String等复杂变量范例构成。假如想移除冗余而且简单招致堕落的ORM代码,可使用AutoMapper.假如想要懂得更多，我保举浏览：ASP.NETMVCViewModelPatterns，那末范畴模子（DomainModel）和视图模子（ViewModel）有甚么分歧呢？
在ASP.NETMVC的使用程序中常常能够能够看到ViewModel，常常我们都以为范畴模子和视图模子是统一个器材。这出格是把范畴模子包括在数据传输工具DTO里的时分，比方利用EntityFramework之类的ORM工具天生的实体。在这类情形下，范畴模子和视图模子包括的实体十分类似，都是一些复杂的CRUD操纵。
这些实体有很多属性，有不异或相似的称号，你能够很简单地映照范畴实体对应视图模子中的一个属性。不外，这些类似的属性也大概略有分歧，比方范例大概格局。比方，用户填写的用户界面的一个属性，他在视图模子里多是一个“Nullable”的。
另外一方面，范畴实体大概必要一个经由考证的正当的值，以是必要一个在用户界面的范畴模子之间的转换。另外一个例子是，用户界面大概会显现一个滑块，用于用户选择几天今后提交他的定单。在这类情形下，视图模子大概利用一个整数属性来暗示，范畴模子一般是一个日期值。
视图模子一般只包括范畴模子的一个子集，并且只包括界面上所必要的属性。别的，视图模子多是一个范畴模子树的扁平版本，比方，一个Customer实体有一个Address，而这又是一个全体，它包括街道地点，邮政编码，国度等。一个Customer视图模子用于显现数据，将地点数据拉平添补到视图模子类里。
别的假如一个View必要同时处置几个范畴模子，ViewModel就是这几个DomainModel的总和。范畴模子和视图模子之间有良多类似的中央，我们常常爽性就把DomainModel看成ViewModel来利用了。下面会商了范畴模子和视图模子的类似性，我们来看看都有几种体例把范畴模子转换为视图模子，一般有3种办法：
1.把范畴模子看成视图模子来用，也就是范畴模子就是视图模子，年夜部分都是这么用的。
2.视图模子内里包括一个范畴模子，界说一个视图模子，内里包括了一个范畴模子，经由过程属性体例举行会见。
3.将范畴模子映照到视图模子，范畴模子并没有间接映照到视图模子，必要处置这类映照干系。
我们不倡议间接把范畴模子实体表露给视图，由于有很多渺小的地方，大概招致您夹杂营业和暗示层的逻辑，不管是范畴实体的属性显现仍是营业的考证划定规矩，这都是使用程序处置的分歧方面。
间接将你的范畴模子作为Conroller上的处置参数面对着平安风险，由于Controller大概Modelbinder必需确保属性考证和用户不克不及修正她本人不克不及修正的属性（比方，用户手动更新了一个埋没的输出值，或增添一个分外的属性值，而这个并非界面上的元素，但却恰好范畴模子实体的属性，这类风险叫做“over-posting”），即便对以后版本的范畴模子做了准确的考证，范畴模子未来大概做了变动修正，并没有呈现编译毛病大概告诫，大概招致新的风险。
我们应该制止利用前两种办法将范畴模子转换成视图模子，保举利用第三种办法，界说独自的视图模子类。做这类范畴模子到视图模子的转换事情是一种反复性的事情，已有几个工具能够匡助你来完成这项事情。最经常使用的一个工具就是.NET社区的开源项目AutoMapper。
文章转自自在、立异、研讨、探究的博客，
原文地点：http://www.ckuyun.com/shanyou/archive/2010/04/03/1703501.html
<p>刚刚打开这篇专题，猛然见到HAL9000发表的《对于大型公司项目平台选择j2ee的几层认识》系列，深受启发。

当然我们在选择Asp.net主机是，除了要考虑服务提供商在版本是否是实时更新以外，机房的环境和配置也是非常重要的，通常选择骨干网的机房，在速度和稳定性上会非常有保证。

PHP的源代码完全公开，在OpenSource意识抬头的今天，它更是这方面的中流砥柱。不断地有新的函数库加入，以及不停地更新，使得PHP无论在UNIX或是Win32的平台上都可以有更多新的功能。它提供丰富的函数，使得在程式设计方面有着更好的资源。目前PHP的最新版本为4.1.1，它可以在Win32以及UNIX/Linux等几乎所有的平台上良好工作。PHP在4.0版后使用了全新的Zend引擎，其在最佳化之后的效率，比较传统CGI或者ASP等技术有了更好的表现。

Asp.net：首先来说，Asp.net和Asp没什么关系，看着像是升级版本什么的，其实没什么联系。Asp是脚本编程，用的是ASP语言，而ASP.net用的是C#语言，完全不同的东西。

主流网站开发语言之CGI:CGI就是公共网关接口(CommonGatewayInterface)的缩写。它是最早被用来建立动态网站的后台技术。这种技术可以使用各种语言来编写后台程序，例如C，C++，Java，Pascal等。

HTML:当然这是网页最基本的语言,每一个服务器语言都需要它的支持,要学习,这个肯定是开始,不说了.

ASP.net的速度是ASP不能比拟的。ASP.net是编译语言，所以，当第一次加载的时候，它会把所有的程序进行编译(其中包括worker进程，还有对语法进行编译，形成一个程序集)，当程序编译后，执行速度几乎为0。

ASP.net的服务器，要求安装一个.net环境，当然我这里指的是windows系统，顺便点一下，.net只能放在windows环境里来运行。Asp.net1.1的就装Framework1.1，Asp.net2.0的就装Framework2.0。