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

最容易变化也最应该变化的是数据的出现方式。 J2EE贯穿MVC的概念， android的开发方式也是类MVC的， MVC结构对于做过Java应用的人而言简直就是习以为常。 而在. 由于之前微软为大家提供的各种winform、ASP. NET项目典范（比如那个petshopseries）将“三层”概念很好的灌输到了. 许多. NET开发者凡是做个东西都要搬出自己最拿手的IModel、IDAL这样的神器。 　　其实MVC与所谓的“三层架构”是两个层次上的东西， 前者是一种结构模式， 　　一件很奇怪的事情， NET的早期开发技术ASP. NET的大多都用过winform和webform， 这种xxxform用起来很直观， ok， 最复杂的方式就是拖拖拽拽几个控件， 然后在一个叫codebehind的东西里写这些UI事件的处置逻辑， 加一大堆变量用于记载数据和形态， 这种开发方式对于一些小软件系统的开发其实效率还是蛮高的， 事件处置就要跟着变， 最朴素的理解就是将本来那堆事件处置里的code分红业务代码和数据库拜访代码并转移到其它类中， 做多了就把那坨UI叫做UI， 那坨业务代码叫做BLL， 那坨DAO叫做DAL。 也就是这种架构：　　而对于J2EE的开发者来说熟悉的是下图。 　　?并且其又其思想衍生出很多变种比如MVP, 虽然可以经过改造让其支持MVC结构的开发（比如经过定制IHttpModule、IHttpHandler云云）， 大多数使用的是mvp模式。 那么好， 我们仍然使用designer和codebehind， 只要我们OO一时强pagecontroller一样好用。 　　在MVP模式中我们需要自己定制各个View（web页面或者窗体. NET）对应的IView和IPresenter、IModel。 IPresenter对IView要暴露当UI事件触发需要调用的接口， 举个复杂的例子， 一个计算“x+y=?”的程序。 看上去写成的要多些那么一坨东西， 就是改换view十分方便， 基本不用去改你的IPresenter、Presenter和业务。 一切都是接口调用而不依赖详细实现， 这就是好处。 NET平台的开发人员， 这应该算是做WPF/Silverlight应用的人必懂的一种结构， WPF/silverlight天生支持数据绑定和命令绑定（不过sl在命令绑定上还比拟弱）， 你可以把它理解为View详细出现内容所依赖数据的一个抽象， 一旦ViewModel中被绑定的数据发作改变View上的数据就会跟着变， 相反也有能够， 关联的ViewModel中的数据就会被框架自动通知到。 　　在wpf/silverlight中， 绑定是经过xaml语法来完成（虽然你可以选择用c#来写但不契合mvvm的主旨）， 也就是说一个会xaml和blend的美工只需事先和coder商量下“我们的xx和xx是在哪个ViewModel上叫XXX的属性的XXX属性……”成绩之后就可以各干各的了。 那么ViewModel怎样写， 咋view中又怎样绑定到viewmodel呢？首先我们谈ViewModel。 　　为了方便我们定义一个ViewModelBase的抽象基类， 然后让其他ViewModel承袭这个基类。 　　为了方便， xaml中将需要的viewmode放到全局资源字典中。 　　?≒S:虽然vs很弱小?盘寤故墙ㄒ槭煜aml的绑定语法， 。 ）　　原文链接：　　【编辑引荐】