.NET程序员应该熟悉的开发模式

最容易变化也最应该变化的是数据的出现方式。 　　在Java的各类应用中能够说是四处可见MVC， J2EE贯穿MVC的概念， android的开发方式也是类MVC的， MVC结构对于作过Java应用的人而言简直就是习觉得常。 NET这边， 因为以前微软为你们提供的各类winform、ASP. NET项目模范（好比那个petshopseries）将“三层”概念很好的灌输到了. NET程序员的大脑中， 许多. NET开发者凡是作个东西都要搬出本身最拿手的IModel、IDAL这样的神器。 然后者则是分层的角度去说。 　　一件很奇怪的事情， 其实这要归结与. NET的早期开发技术ASP. NET和winform这些pagecontroller的模范让许多人对三层夸夸其谈却对MVC视而不见甚至一无所知。 什么是pagecontroller形式呢？搞. NET的大多都用过winform和webform， 咱们想要作一个程序， ok， 最复杂的方式就是拖拖拽拽几个控件， 而后在一个叫codebehind的东西里写这些UI事情的处置逻辑， 这样一个程序就能出炉。 这种开发方式对于一些小软件系统的开发其实效率仍是蛮高的， 后来人们看到其弊端---一旦修正UI， 事情处置就要跟着变， 可是业务仍是那个业务， 凭什么要修正非UI的代码？因而有人提出“三层”， 最朴素的理解就是将本来那堆事情处置里的code分成业务代码和数据库访问代码并转移到其它类中， 作多了就把那坨UI叫作UI， ú鳎赫饬椒糲opy自是daxnet文）　　MVC是一个很经典的结构， 而且其又其思想衍生出不少变种好比MVP, 传统的MVC结构之一是这样的（拿自动型MVC来讲）：　　对于非天然MVC的框架　　对于ASP. 虽然能够通过改造让其支持MVC结构的开发（好比通过定制IHttpModule、IHttpHandler云云）， 可是在企业看来这些都算是邪门武功（由于这样会丧失xxxform在开发上的不少特性好比疾速开发）。 什么是mvp呢？其实mvp是MVC的一个变种。 那么好， 咱们仍然使用designer和codebehind， 其实一个架构设计的好坏是取决于人而不是详细的技术的， 只需咱们OO一时强pagecontroller同样好用。 　　在MVP形式中咱们须要本身定制各个View（web页面或许窗体. NET）对应的IView和IPresenter、IModel。 IView要对IPresenter暴露操做UI、数据绑定的接口， 举个复杂的例子， 看上去写成的要多些那么一坨东西， 可是益处是显而易见的， 这就是益处。 NET平台的开发人员， 托微软的福分咱们拥有一种更为强大的模型---MVVM。 这应该算是作WPF/Silverlight应用的人必懂的一种结构， 这就为咱们使用MVVM创造了可能。 　　View是什么呢， 纯的View只有xaml或许附带必要的只与View自己相关逻辑代码。 在MVVM中View与ViewModel总会有一种绑定关系， 一旦ViewModel中被绑定的数据发生改变View上的数据就会跟着变， 好比你的帐号密码框内容发生变化， 关联的ViewModel中的数据就会被框架自动通知到。 绑定是通过xaml语法来完成（虽然你能够选择用c#来写但不符合mvvm的宗旨）， 而且绑定双方的通知机制是有框架来完成， 也就是说一个会xaml和blend的美工只需事前和coder商量下“我们的xx和xx是在哪一个ViewModel上叫XXX的属性的XXX属性……”效果以后就能够各干各的了。 那么ViewModel怎么写， 咋view中又怎么绑定到viewmodel呢？首先咱们谈ViewModel。 而后让其余ViewModel继承这个基类。 　　为了方便， 咱们能够在app. 　　?≒S:虽然vs很强大， 但我的仍是建议熟悉xaml的绑定语法， 想当初用vs2008搞wpf的时候貌似尚未这么方便的设计器。 。 ）　　原文连接：　　【编辑引荐】