【IT168 评论】前段时间有个兄弟问我wcsf的问题,说实话,第一次听到这玩意,我一开始还以为他说wcf呢,寒。网上一搜,哦~~原来这是practice and pattern team的大作,于是用了两周的时间研究了一把,发觉这套东西的确很强,由于那个兄弟是要为自己的公司选架构,所以我就趁此机会分析了下他们的异同和优缺点。
WCSF是啥?
WCSF全称Web Client Software Factory, 貌似08年就已经很成熟了,最近还出了vs2010版,可惜我机器上vs2010死活装不上去,老报2908和1935(已在microsoft connect上提交bug,希望vs team会瞧一眼),所以只能看基于vs2008的wcsf,其实vs2005 wcsf也是支持的。尽管这套框架很成熟,但似乎国内很少有人讨论,即使是国外的blog也只有少数几个作者在写教程,不知道是推广没做好还是啥原因。
详见http://msdn.microsoft.com/en-us/library/ff648752.aspx
ASP.NET MVC是啥?
ASP.NET MVC是微软最新推出的web编程框架,从名字就可以看出MVC模式是这个框架的重点。这是微软重点推的开发框架,目前已经出了2.0版。
详见http://www.asp.net/mvc
以下是功能对照表
WCSF | ASP.NET MVC | |
开发模式 | MVP | MVC |
开发指导文档 (官方) | 有 | 有 |
开发指导文档 (民间) | 少 | 多 |
测试指导文档(官方) | 有 | 有 |
测试指导文档(民间) | 少 | 多 |
开发平台支持 | vs2005, vs2008, vs2010 | vs2008 sp1, vs2010 |
使用ASP.NET web controls | 能 | 不能 |
模块化加载 | 支持 | 无 |
Web视图引擎 | 无 | 好多 |
模板引擎 | 有 | 有 |
页面流程控制 | 有 | 无 |
内嵌MockObject | 有 | 无 |
支持master page | 支持 | 支持 |
安全认证支持 | EnterpriseLibrary.Security | ASP.NET安全机制 |
内嵌EnterpriseLibrary | 是 | 否 |
页面响应机制 | ASP.NET postback | url routing |
代码与UI分离 | 强 | 较强 |
业务层单元测试 | 支持,并有详细指导文档 | 支持 |
UI层(Controller, Presenter)单元测试 | 支持 | 支持,有详细文档 |
前台(javascript)单元测试 | 无,需自己开发 | 无,需自己开发 |
javascript库 | 无自带库,但可根据需要嵌入 | jquery, asp.net ajax framework |
说到架构选择,我们就不得不提几个必须考虑的问题:
1. 雇佣成本
这个是做任何事必须要考虑的问题,对于公司来说降低成本是非常重要的(虽然大公司有很多钱可以烧,也有闲人可以养),HR和老板应该会对这个很感兴趣。从目前来看,WCSF由于国内使用的人较少,其雇佣成本会略高于ASP.NET MVC,并且使用WCSF的人对于架构的理解可能要比ASP.NET MVC更加深入些,毕竟ASP.NET MVC的架构远比WCSF简单,当然这也间接说明ASP.NET MVC架构的透明度做得比WCSF要好,能够让一些初级程序员不需要知道具体实现就可以使用它。
2. 培训成本
从目前的文档情况来看,wcsf的文档(包括民间blog)远少于ASP.NET mvc,再加上WCSF把很多东西都包括了进去,所以其培训成本将远高于ASP.NET MVC。另外,由于微软重点推广ASP.NET MVC,似乎只要是用ASP.NET的人基本都知道ASP.NET MVC,或多或少会有些概念。另外由于ASP.NET MVC支持多种web视图引擎,从一定意义上讲,这会降低一定的培训成本,因为不排除有些程序员曾经使用过其他平台上的视图引擎,转过来会很方便。
2. 性能
但从这两个架构来说,并不存在很明显的性能差别,这主要还是取决于使用的人。在使用WCSF的时候,必须注意ViewState的使用,一旦ViewState泛滥,将直接导致页面过大,而引起性能下降。另外,wcsf使用了Object Builder,所以必须考虑其构建对象的性能,并对一些对象做适当的缓存处理,以减少反射带来的性能影响(据说WCSF新版本使用了DynamicMethod,这东西的性能我测过,确实能比反射快很多)。ASP.NET MVC由于架构相对简单,也没有ViewState,就目前来看不会有性能问题,当然最终的性能还是取决于开发的代码质量。
3. 可扩展性
WCSF在可扩展性方面更胜一筹,因为它为你提供了很多选择,比如说模块化加载、页面流程控制、Guidance Automation,以及Enterprise Library本身提供的各种扩展功能,并且这些功能在WCSF的文档中已经有了很明确的指示,谁该用哪些功能,例如架构师应该用Guidance Automation Tookit和Guidance Automation Extension,而开发人员应该使用Automation Package,并且这些东西能与VS完美融合,这样也可以在无形中限制初中级开发人员的行为,而不是让他们“为所欲为”。ASP.NET MVC尽管也提供了例如Area、模板引擎,但其文档并没有明确指出架构师应该负责哪些部分,并且也没有和VS融合,只能通过文档来约束开发人员的行为和代码。
4. 可测试性
从白盒测试角度看,这两个东西的可测试性基本相当。ASP.NET MVC由于MVC模式本身的优势,基于Controller、Model和HtmlHelper的单元测试很容易写,基本没有什么限制,只是View的测试就相对比较困难。而WCSF由于采用了MVP模式,尽管提升了UI和代码分离的程度,但是做Presenter的事件测试稍微麻烦一点,但总体不影响单元测试的进行。
5. 后期维护成本
(这个就目前我对这两样东西的了解,还很难做出比较合理的分析,也没有具体实践的项目,如果有兄弟有较好的分析方法可以写在回复中。)
6. 移植成本
如果公司以前采用的是ASP进行编码,转换成WCSF和ASP.NET MVC的成本基本相当,说白了都是重新写。如果公司以前有过分层设计,且假设有服务层、业务逻辑层、数据层三层,那么业务逻辑层和数据层基本可以不动,但是服务层会有所变化,主要要适应新的调用方式,以及实现接口。相对而言,由于ASP.NET MVC没有实现太多的东西,相对WCSF而言,从以前的代码移植到ASP.NET MVC反而相对容易些,这和之前提到的培训成本也是有关系的,尽管我们要自己搭一些架构,比如身份认证、权限控制、流程控制等。当然有人会指责这有“重新发明轮子”的嫌疑。