ASP.NET网页设计MVVM启发录仓酷云
一般的指的.net就是跟net网页编程相对的那种，主要是做企业级应用的。你如果想学这个，主要就是学C#和数据库。(ASP.NET好像很重要的，应该也要学的，ASP.NET上好像可以结合VB和C#等多种语言，但是微软主推C#）细究MVVM熟习WPF或Silverlight的同砚应当不会对MVVM形式感应生疏了，它把使用程序分别成视图、视图模子和模子三层，如所示：
外表上，这个条理布局还蛮分明的，但假如你细究每层应当包括甚么，事变就没那末复杂了。
视图应当是最简单了解的一个部分了，它一般是指用户能够看到的界面，一样平常都是经由过程XAML代码来完成的。可是，XAML代码其实不能完成统统想要的效果，这个时分良多人会把眼光投向代码埋没文件，在内里经由过程事务处置程序完成某些效果。那末，事实甚么样的代码能够放在代码埋没文件里？这些代码是不是包括底本应当放在视图模子里的代码？这些效果是不是另有其他路子能够完成？
视图模子从字眼上看应当是视图的笼统，这意味着每一个视图都应当有一个对应的视图模子，这也是我们常常看到的做法。不外，有人对此暗示否决，他们以为视图和视图模子不是逐一对应的干系，全部使用程序应当有一个次要的视图模子，各个视图将会绑到这个次要的视图模子上，同时有一些主要的视图模子，用来暗示诸如设置等帮助方面。那种做法才是准确的？视图模子内里又该包括甚么样的代码？
最初是模子，年夜多半人对它的一个共鸣就是，它会包括详细的数据，这些数据终极会显现到用户界面上。成绩是，它究竟是复杂的POCO仍是营业逻辑的庞大范例？我们是不是应当在这里安排考证逻辑？是不是同意它和视图间接绑定，仍是必要别的创立对应的包装类？假如利用LINQtoSQL存储数据的话，模子里的类是不是就是LINQtoSQL的实体类？假如必要会见WebService猎取数据，模子里的类和增加WebService时主动天生的类又是甚么干系？
哇，成绩还真很多啊！你是不是已经碰到这些成绩？你对它们有甚么设法？固然，这些成绩没有独一的尺度谜底，它们都是开辟者在详细理论中提炼和总结出来的伶俐，但它们一般只针关于特定的使用场景，大概说，它们是为了满意某些必要而发生的。举个例子吧，有些人大概会以为增加WebService时主动天生的类和他们要创立的模子类基础上是分歧的，为了不反复休息，他们选择间接利用那些主动天生的类，这类做法一样平常不会呈现成绩，直到因为需求的变动，模子不再和WebService对应起来，但此时使用程序的其他部分已经由过程这些主动天生的类和WebService严密耦合起来了，修正使用程序便可能变得十分坚苦。相反，假如使用程序的功效对照单1、专注，WebService的接口也对照不乱，那末特地为那些主动天生的类创立一组千篇一律的模子类明显增添休息本钱，埋下潜伏的保护成绩。
最复杂的完成
假定我常常往藏书楼借书，我必要一个使用检察一切图书的偿还日期，如所示：
这是一个十分复杂的使用，从MVVM形式的角度来看，所展现的用户界面就是视图了，而视图模子和模子也都十分复杂，分离为的MainViewModel类和Book类：
页面的ListBox控件将会绑到MainViewModel的Books属性，书名将会绑到Book的Title属性，而偿还日期则绑到Book的DueDate。
到今朝为止，统统都十分天然顺畅，直到我对它提出两个新的需求：
[*]图书列表依据偿还日期从小到年夜排序，即开始要还的书拍在最下面。
[*]明天和今天要还的书字体利用夸大色。
这两个新的需求都十分公道。第一个需求属于页面的笼统逻辑，不与页面的任何控件挂钩，这类需求一样平常会在视图模子内里完成，详细地就是在MainViewModel的机关函数里初始化Books属性时举行升序排序。
至于第二个需求，它触及到详细的TextBlock控件和对Book类的DueDate属性的二次处置，准绳上不该该在Book类内里完成，依据团体偏好，这个需求有两种分歧的完成体例：
[*]创立一个ItemViewModel类，包装Book类并表露相干属性，同时供应一个Foreground属性用于和TextBlock控件的对应属性绑定，Foreground属性能够在初始化ItemViewModel时依据Book的DueDate属性盘算。
[*]经由过程转换器完成不异的效果。
有人说，利用MVVM形式能够打消转换器的必要，是的，任什么时候候当你必要一个转换器，你都能够经由过程创立包装类并供应分外的属性取得不异的效果，但我们不该该把这个成绩相对化，转换器的存在代价表现在能够在分歧的绑定干系上重用不异的逻辑，并且更切合ExpressionBlend用户的利用习气。
看到这里，有些同砚大概会问，假如用户请求同时供应依据图书题目和偿还日期两种排序体例呢？每当我们碰到一个新的需求时，请不要即刻下手完成大概思索怎样完成，应当先想一想用户为何有如许的需求。依据偿还日期举行排序这个需求对应着匡助用户制止过期偿还所受的处分，但依据图书题目排序呢？良多时分，我们会想固然地以为用户必要某些功效，而疏忽用户真实的需求，如许不仅会招致功效冗余，还会分离用户关于最主要功效的注重。现实上，依据图书题目排序这个需求极可能是想匡助用户懂得某本书是不是已存在于列表中，大概某本书的详细信息，如还能够读多久，实质上，这个需求极可能是匡助用户从列表中疾速查找某本书。假如是如许，为何不思索给出一个立即搜刮的功效，好比说，当用户单击搜刮按钮时，会显现一个搜刮框，用户在内里输出关头字，图书列表即刻显现包括该关头字的图书？
命令与操纵
到今朝为止，这个使用几近能够说一无可取，由于它不撑持增加、编纂和删除等操纵，那末，完成这些操纵又有哪些工具必要思索呢？假定我们在用户界面上增加响应的按钮和菜单，如所示：
以往的做法是在代码埋没文件里经由过程事务处置程序来完成，但在MVVM形式里，我们倡始经由过程命令对象来完成，成绩是，这些命令对象在哪完成？增加操纵是页面局限的，与之对应的命令对象能够在MainViewModel类里完成，但编纂和删除两个操纵对应于Book类，那末，我们是不是应当在Book类里增加响应的举动？
有一部分人对此的概念是，模子并不是纯真的POCO，而是完全的范畴模子，能够包括区分于页面逻辑的营业逻辑，而且不会和ORM的实体类同等起来，如许做的优点是我们有一个一致的中央来保护全部使用的形态，也和详细的数据层解耦，不管数据终极来自当地仍是远程服务，都不会影响在此之上的工具，与此同时，我们也不用在为分歧的视图模子之间怎样传送数据感应懊恼。固然，如许做的害处也是分明的，它引进了大批大概不用要的庞大性，关于小型项目具有很多杀伤力。
假如我们不在Book类里增加举动，又不想在代码埋没文件里经由过程事务处置程序来完成这些操纵，那末我们就必要思索一下ExpressionBlend的举动（Behavior）了。详细的设法是如许的，假定用户单击编纂菜单项的时分将会翻开EditItemPage.xaml页面，而这个页面必要晓得用户选中哪本图书，那末全部操纵就能够看做经由过程NavitagionService.Navigate办法翻开“EditItemPage.xaml?title=XXX”如许的链接了。要完成如许的效果，你可使用AppBarUtilsforWindowsPhoneSDK7.1的NavigateWithQueryStringAction，如代码1所示：
<AppBarUtils:NavigateWithQueryStringActionTargetPage="/EditItemPage.xaml"><AppBarUtils:ParameterField="title"Value="{BindingTitle}"/></AppBarUtils:NavigateWithQueryStringAction>代码1
共同EventTrigger在MenuItem上利用就能够完成预期的效果了。
除此以外，你也能够思索创立一个ItemViewModel类，然后在下面完成编纂操纵的命令对象，然后和MenuItem的Command属性举行绑定。假如你选择这类做法，就会无可制止地碰到在视图模子里翻开页面的成绩。我们一般用来翻开页面的NavitagionService.Navigate办法必需在页面的局限内才可会见，但视图模子关于视图一窍不通，怎样挪用这个办法？
罕见的做法是封装PhoneApplicationFrame的Navigate办法。当你用VisualStudio创立一个WindowsPhone项目时，App类内里会有一个RootFrame属性，你能够经由过程这个属性挪用PhoneApplicationFrame的Navigate办法。现实上，PhoneApplicationFrame和页面是共用统一个NavitagionService对象的。
删除操纵是一种很出格的操纵，它同时触及到汇合和内里的元素，但在XAML里，MenuItem只能从父元素承继对应的Book对象，却无从晓得包括该对象的汇合，这为完成删除操纵形成极年夜困扰。罕见的办理举措是把MainViewModel作为一个静态属性放在App类里，如许你就能够容易会见到包括Book对象的Books汇合。从这个角度来看，假如我们一入手下手就把模子计划成范畴模子，卖力办理和保护范畴对象的形态，那末如今就不用把某个视图模子硬塞到App类里了。
使用程序栏和其他
在WindowsPhone上利用MVVM形式一定会碰到的一个停滞就是使用程序栏，它的成绩在于它不是Silverlight控件，而是体系组件，这意味着它没法像一般的Silverlight控件那样举行数据绑定。市情上有很多办理计划，个中之一就是后面提到的AppBarUtilsforWindowsPhoneSDK7.1，有乐趣的能够看看AllenLee写的《AppBarUtils利用指南》。
假如你把模子计划成范畴模子，那末你必定要注重WindowsPhone的“深度链接”（deeplink），这类情形会在你利用Toast关照和主要磁贴（secondarytile），并在用户单击翻开使用的某个页面时呈现。因为用户仅对某个页面感乐趣，并且当用户按前往键时会间接加入使用而不是依照使用的惯例逻辑前往上一页，因而构建全部范畴模子会显得劳师动众、泯灭资本。
有人以为，利用MVVM形式的一年夜优点是为ExpressionBlend用户带来便当，的确是如许，数据绑定和命令对象的使用使得ExpressionBlend用户更容易经由过程可视化操纵利用开辟职员的背景代码。假如你的视图模子也会给ExpressionBlend用户利用，那末你必需思索的一点就是在视图模子里供应计划时数据，特别是你的逻辑包括会见当地数据库大概WebService，由于在ExpressionBlend的计划器里没法实行这些代码。
最初不能不提的是，MVVM形式使得我们能够绕过用户界面临使用的功效举行测试，包含单位测试，假如你有乐趣，能够看看Chenkai的《Windowsphone使用开辟-单位测试》。
我觉得很重要，一般所说的不重要应该指的是：你学好一种以后再学另一种就很容易了。（因为这样大家可能有一个错觉就是语言不是很重要，只要随便学一种就可以了，其实不是这样的。 通过这次激烈的讨论，我从大家身上学到了太多，开阔了眼界，不管是支持我的还是骂我的，都感谢你们。 CGI程序在运行的时候，首先是客户向服务器上的CGI程序发送一个请求，服务器接收到客户的请求后，就会打开一个新的Process（进程）来执行CGI程序，处理客户的请求。CGI程序最后将执行的结果（HTML页面代码）传回给客户。 Asp.net脚本的出现，为ASP空间带来了更高的稳定性，同时也为程序员建站提供更高环境! 是目前ASP在UNIX/Linux上的应用可以说几乎为0）。所以平台的局限性和ASP自身的安全性限制了ASP的广泛应用。 虽然在形式上JSP和ASP或PHP看上去很相似——都可以被内嵌在HTML代码中。但是，它的执行方式和ASP或PHP完全不同。在JSP被执行的时候，JSP文件被JSP解释器（JSPParser）转换成Servlet代码，然后Servlet代码被Java编译器编译成.class字节文件，这样就由生成的Servlet来对客户端应答。所以，JSP可以看做是Servlet的脚本语言（ScriptLanguage）版。 Servlet的形式和前面讲的CGI差不多，它是HTML代码和后台程序分开的。它们的启动原理也差不多，都是服务器接到客户端的请求后，进行应答。不同的是，CGI对每个客户请求都打开一个进程（Process）。 主流网站开发语言之PHP:PHP的全名非常有趣，它是一个巢状的缩写名称——“PHP:HypertextPreprocessor”，打开缩写还是缩写。PHP是一种HTML内嵌式的语言(就像上面讲的ASP那样)。而PHP独特的语法混合了C，Java，Perl以及PHP式的新语法。它可以比CGI或者Perl更快速地执行动态网页。 ASP在执行的时候，是由IIS调用程序引擎，解释执行嵌在HTML中的ASP代码，最终将结果和原来的HTML一同送往客户端。 如今主流的Web服务器软件主要由IIS或Apache组成。IIS支持ASP且只能运行在Windows平台下，Apache支持PHP，CGI，JSP且可运行于多种平台，虽然Apache是世界使用排名第一的Web服务器平台。 asp.net最主要特性包括：◆编程代码更简洁◆网站可实现的功能更强大◆运行效率高◆节省服务器的动作资源 现在的ASP.net分为两个版本：1.1和2.0Asp.net1.1用VS2003(visualstudio2003)编程。Asp.net2.0用VS2005(visualstudio2005)编程。现在一般开发用的是VS2003。
页:
[1]