小A是支枪，子弹未打光----之"步枪"篇
在上一篇文章中，小A从学校出来到进入公司做网站开发这一年半左右的时间内，逐步从一个新手
成长为一名有一定开发经验的web程序员．其自身所学习的领域也进一步扩展，同时其开发语言也从
asp转型到.net平台上来．但小A似乎总感觉缺些什么，那就是之前在学校中听说但未曾真正理解和使
用的设计模式（这里特指面向对象的23个设计模式），尽管自己使用的也是支持面向对象的C#语言，
但总感觉平时写代码时只是将C#当做是更高级的C语言来使用（相信很多开发人员都经历过这个阶段）．
而其所写的代码也随着业务逻辑的不断变化和复杂性增加而不断修改．在那段时间里，小A越来越
感觉对项目的把控能力不足，力不从心．经常费寝忘食的调试程序和寻找BUG．同时因为没有对所开发
的程序进行分层，导致前台显示，业务控件逻辑和SQL语句同时混在一个aspx.cs文件中，页面中代码
量太大，这也给后期维护和调试造成诸多不便．当然更要命的就是重复代码因为频繁剪切粘帖已到了
跟"刻章办证"小广告一样普遍的程度．看着这些之前没处理过的问题小A又开始茫然了．好在之前学过
一些面向对象语言的知识，这时开始逐步尝试对已有的混乱代码进行分解归纳．按执行的业务逻辑先
将过长的函数分解为多个短小且可供重用的方法，再将相似的方法按业务逻辑归纳到相同的类中．这
时微软已提供了Duwamish这个DEMO，通过参考这个项目，逐步把已有的网站架构进行分层．
先是业务实体层和数据访问层，然后是业务规则层和业务外观层，最后是web层．一层分解出来
后，虽然代码量比以前更多了，但结构却是前所未有的清晰．另外调试也比以前方便了，因为数据显
示层很少出错，而经常出问题和需要变动的是业务规则层和业务外观层（业务实体层变动较少）．而
这两个层中以业务规则层变动最为活跃，所以可以集中精力和时间来认真分析设计和调试这一层代码．
而这时小A开始注意到设计模式可以帮助程序员将频繁变动的(业务) 代码与不变（或者很少变动）的
代码之间解藕．以此为出发点，小A踏上了开始学习和实践设计模式的"不归路"．
要学习就要有资料的来源，而那时教授设计模式的书所使用的语言要么是JAVA,要么是C++．C#
的可以说是"一穷二白"．而那时博客园里还不像如今这样内容丰富．所以当时只有采用迂回策略，先简
单学习JAVA再研究设计模式（起码要先搞清在JAVA中继承和重写是如何实现）．好在那时的JDON论
坛有很多设计模式的文章和相关讨论．小A 就注册了帐号长期潜水下来，而最开始看的四个模式包括：
Singleton, Composite, Streatgy, Decorate模式．而为什么是这四个模式呢，主要是看了论坛中
有位"老手"在回答设计模式"新手"问题时所做的陈述，即它们比较好区分且应用的比较广泛．而即便是
这四个所谓区别比较明显的模式也让小A费了些时日才搞明白．而如何在实际开发中使用小A心里还是
没底，所以总想找机会使用一下新学习的成果．当然如果能找到一个使用模式技术架构的软件的话，
并深入研究它，可能会收到更好的效果．
另外在一次面试时，面试官也问到了有关设计模式的问题，当时只是让小A简单谈一下，但因为因
刚接触不久，小A聊的驴唇不对马嘴．让考官颇感失望，在回家的路上，小A倒是没感觉多么沮丧，为
自己终于找对了方向，感到前方的道路虽然坎坷但一片光明．
唯一遗憾的是这时市面上关于开发.net应用中使用设计模式的图书还是不多，而JAVA那边从应用
框架到设计模式讲解的图书却是扑天盖到．小A这面感到茫然了，主要是感觉没有高人指点．下一步该
如何学习模式还是看些其实什么东西呢？
小A带着这样的疑问过了几个月，直到2004年初在市面上看到了<<程序员>>2003年合订本之后
才像找到了魂一样．因为在该合订本中，关于设计模式的讨论特别是在一个C++开源框架中使用设计
模式的分析中（请参见这篇文章），一个名字走入其视野，"马维达"先生用他点睛之笔，帮助研究和
使用ACE的C++同行们找到了学习ACE的方法，其所翻译的C++网络编程（1,2卷，候捷推荐）也成
为了那一年市面上少有的几本好书之一．接下来的日子里，小A因为有C++的一些基础（起码比JAVA
熟悉），开始了按书中所说内容在ACE框架海洋中畅游的"旅程"（也可能就是因为有了这块敲门砖，
才真正知道什么才是框架，以及满足面向行业应用而开发设计的框架应该是个什么样子）．
接下来整整两年的日子类似于苦行僧，一方面是模式学习，一边是框架学习．模式从创建型到结
构型再到行为型，框架逐步从ACE真正转移到.net下的框架. 与同事和朋友MSN,QQ上聊的也是NH-
ibernate，Ibatisnet,Spring.net, castle之类的.net框架，好在这时博客园也日渐热闹起来，也
开始有模式和框架学习的文章陆续发表．至今小A还记得最早在园子里看到的框架的文章就是"叶子的家"
发表的关于castle, 以及后来陆续出现的研究学习NHibernate，Ibatisnet，log4的文章．其实在一
开始实际用使用的是castle，主要是当时公司里对自己所在的开发小组在项目开发时间上不作严格要
求，所以小A就利用这一点，在一开始时将了解的castle方面的东东用到了项目中，而这次不成功的
使用才让小A了解到框架如果用的不是时机和场合，无论对开发人员还是公司而言都会很"痛苦"．
虽然Castle有非常好的各种特性，ActiveRecord，MonoRail, MicroKernel/Windsor等．且项目
本身虽然时间上充足一些，但如果使用Castle需要深入了解这个框架的人．而如果团队中无人知晓相关
信息，导致学习的成本偏高．另外就是当时使用"Webform+控件"方式开发的同事在公司还是主流，而
MONORAIL方式要求使用NVelocity，大家还要学习这种模版语法，所有不少人打了退膛骨，最终项目
只做了几天就还是回到了老路上．这次尝试以失败告终．但小A还是期待着与CASTLE再次重逢的日子．
另外通过框架来学习设计模式也是一个不错的选择，必定应用型框架本身要求模块化，可重用性和
可扩展性，简单性及可维护性．是开发人员思想的深度锤练．
注：说到了Castle，这里不得不聊些题外话了．因为这一年以来随着monorail与微软的MVC框架
关系越来越暧昧．导致一些朋友开始对monorail的前途感到迷盲．Hamilton Verissimo之前表示过如
果MVC正式版没有其所希望的那样（存在分歧），他会考虑继续monorail的后续开发．而随着其加入
微软之后，他本人的活动显然没有以前在CASTLE官方社区中那样活跃（大家可以看看那几年他的发帖
和回复量）．在MEF发了 CTP版之后一直没怎么看到其在讨论区活动．这与以前那个在开源社区中的
"活跃分子"形象相去甚远．而让我隐约感到不对劲的地方就是其在CASTLE上发过一篇加入微软日志，
从字里行间我没看出多少喜悦之情，倒是某种忧虑萦绕其中．也许他在忙于其在微软工作之后的首次
处女作MEF, 也许是忙于适应新的工作环境．起码其在微软的BLOG上至今仍没什么动静．
另外就是那几年(特别是2003-2004)是AOP和IOC流行的时候，那时如果哪个开源框架不支持这两种
而无论是spring.net和castle都提供了AOP的支持，而CASTLE中用的就是基于动态代理的Aspect#,
而这个AOP框架以Facility工具方式引入到CASTLE框架中．通过该方式还集成了IBatisNet，NHibernate，
Wcf等框架．
虽然在小A的实际开发中没有过多的应用框架来提升开发速度，但研究框架代码的确能够扩展程序员的
视野，提升自己的开发功力和解决问题的能力，还包括思考方式的转变．而真正提升开发速度的倒是Code
－Smith这类的代码生成工具．也许某些人不屑于使用这类工具，认为这是懒人而不是"真正程序员"的所为．
但什么东西也许真正用到才会感到其中的乐趣．因为之前小A已经从那家网站跳槽成功（就在那次失败的面
试后不久），而新公司所给的薪水也是前一家的两倍，但如果想将来买房置业的话，还是不够．这时小A开
始跟其他同事一样，业余时间接私活．并且时常要接1-2家的私活．因为平时只能用下班时间或周六日来干
这些零工，所以时间有限，而客户那边经常又催（甚至在小A上班时使用MSN就接上头了），所以不得不依
懒这些代码生成工具的帮助．并且因为CODESMITH支持模板机制，只要改动很少的代码就能完成定制并生
成自己想要的格式代码，且不会出错，所以这时感到这类工具的确是个好东西．
而这时对设计模式的使用也让小A从中受惠颇多，因为模式本身所讲求的即是灵活复用．小A也不失时
机的对已有的代码进行重构，提练归纳出来了一些代码，采用模式的方式对这些代码进行规划和设计而恰
恰是这些代码在日后开发中被不断的复用到别的项目中，减少了很大的工作量．比如说使用 抽象厂模式
所做的数据库链接类等．
其实这时小A也开始有意无意的注意.net这个框架的一些架构上面的内容，并开始着手考虑开发出一个
自己所处行业的框架．这时在网上看到这本叫做<<应用框架的设计与实现>>一书(之前从网上和书上所看
到的都是如何学习和使用框架的著作和文章)，而这本书恰恰是教你如何设计框架和使用设计模式搭建框架．
这是一个新的切入点，而通过这本书(虽不像那些经典著作那样高深)，的确帮助小A打开了一扇新门，看到
了更广阔的天地．小A不仅自己很快看完了该书，还尽力向同事和朋友推荐．必定好东西要大家共享呀!
这样在那家新公司又渡过了一年半左右的时光，虽然每天很累很忙但很充实．而这时小A也把在CSDN
上的blog搬到了cnblog上，不仅因为这是一片更大的舞台（此时博客园已经成为了国内.net开发人员最大
的社区），并且首页文章的含金量也相当高（信息的燥声要比今天小）．当然入住博客园之后将近半年的
时间小A都在潜水，这主要是因为小A感学自己水平有限且初来轧道，另一方面主要还是时间不够，平时浏
览学习园子里的文章就够喝上一壶的了．
在一年半之后，小A又通过朋友推荐去了一家技术实力更强且有较深厚行业背景的公司，而在这家公司
里面，小A才感受到了业务需求这个以前从未认真对待过的东东是如何左右开发流程的．也才真正认清业务
需求和技术之间的关系．因为之前小A感觉自己的发展方向应该是做软件架构，所以认为技术是第一的，其
他原因只是被放到其后，而那时身边的朋友也都是清一色的技术人员，大家平时谈的最多的也是技术内容．
而在一次MSN上与一个招收架构师的公司聊这个话题时，对方所说的一句话给小A留下了十分深刻的印象．
"架构师应该是面向行业的，换句话说架构师要了解其架构的软件所服务的行业，并能根据公司战略决
策来规划架构软件，使其为公司牟利．"
其实上面所说的部分内容的确被CSDN前一阵子所做的一个视频专访节目中提到过，大家感兴趣可以参
见这个链接：
与知名架构师 周爱民共话架构师程序人生
注：前阵子CSDN在上海搞了个＂英雄会＂，邀请了不少业内知名的CTO来参加，其中有些内容也非常
有代表性．
其实写到这里，大家应该能理解通过设计模式，代码生成工具等手段来提升开发火力这一结论了．而对
框架等内容的理解又可以扩展自己的视野和思考问题的角度，相当于增加了子弹的射程和精确性．所以这时
小A已完成了从手 枪转型为步枪．但事件还没有这样简单，因为正如上面所说，业务需求分析这时真正开始
引起小A的注意，所以这就引出来下一篇的内容，即：
我们将会在下文中，跟小A一起感受"业务需求"在实际开发中所扮演示的角色．并看到小A从一支步枪变成
一支狙击步枪的心路历程．
好了，今天的内容就先到这里了．有兴趣的朋友可以在回复中进行讨论．
tag:开发,webservice,soa,wcf,手 枪,步枪,castle,设计模式,framework
作者:代震军,daizhj
原文链接:http://www.cnblogs.com/daizhj/archive/2008/10/06/1291817.html
成长为一名有一定开发经验的web程序员．其自身所学习的领域也进一步扩展，同时其开发语言也从
asp转型到.net平台上来．但小A似乎总感觉缺些什么，那就是之前在学校中听说但未曾真正理解和使
用的设计模式（这里特指面向对象的23个设计模式），尽管自己使用的也是支持面向对象的C#语言，
但总感觉平时写代码时只是将C#当做是更高级的C语言来使用（相信很多开发人员都经历过这个阶段）．
而其所写的代码也随着业务逻辑的不断变化和复杂性增加而不断修改．在那段时间里，小A越来越
感觉对项目的把控能力不足，力不从心．经常费寝忘食的调试程序和寻找BUG．同时因为没有对所开发
的程序进行分层，导致前台显示，业务控件逻辑和SQL语句同时混在一个aspx.cs文件中，页面中代码
量太大，这也给后期维护和调试造成诸多不便．当然更要命的就是重复代码因为频繁剪切粘帖已到了
跟"刻章办证"小广告一样普遍的程度．看着这些之前没处理过的问题小A又开始茫然了．好在之前学过
一些面向对象语言的知识，这时开始逐步尝试对已有的混乱代码进行分解归纳．按执行的业务逻辑先
将过长的函数分解为多个短小且可供重用的方法，再将相似的方法按业务逻辑归纳到相同的类中．这
时微软已提供了Duwamish这个DEMO，通过参考这个项目，逐步把已有的网站架构进行分层．
先是业务实体层和数据访问层，然后是业务规则层和业务外观层，最后是web层．一层分解出来
后，虽然代码量比以前更多了，但结构却是前所未有的清晰．另外调试也比以前方便了，因为数据显
示层很少出错，而经常出问题和需要变动的是业务规则层和业务外观层（业务实体层变动较少）．而
这两个层中以业务规则层变动最为活跃，所以可以集中精力和时间来认真分析设计和调试这一层代码．
而这时小A开始注意到设计模式可以帮助程序员将频繁变动的(业务) 代码与不变（或者很少变动）的
代码之间解藕．以此为出发点，小A踏上了开始学习和实践设计模式的"不归路"．
要学习就要有资料的来源，而那时教授设计模式的书所使用的语言要么是JAVA,要么是C++．C#
的可以说是"一穷二白"．而那时博客园里还不像如今这样内容丰富．所以当时只有采用迂回策略，先简
单学习JAVA再研究设计模式（起码要先搞清在JAVA中继承和重写是如何实现）．好在那时的JDON论
坛有很多设计模式的文章和相关讨论．小A 就注册了帐号长期潜水下来，而最开始看的四个模式包括：
Singleton, Composite, Streatgy, Decorate模式．而为什么是这四个模式呢，主要是看了论坛中
有位"老手"在回答设计模式"新手"问题时所做的陈述，即它们比较好区分且应用的比较广泛．而即便是
这四个所谓区别比较明显的模式也让小A费了些时日才搞明白．而如何在实际开发中使用小A心里还是
没底，所以总想找机会使用一下新学习的成果．当然如果能找到一个使用模式技术架构的软件的话，
并深入研究它，可能会收到更好的效果．
另外在一次面试时，面试官也问到了有关设计模式的问题，当时只是让小A简单谈一下，但因为因
刚接触不久，小A聊的驴唇不对马嘴．让考官颇感失望，在回家的路上，小A倒是没感觉多么沮丧，为
自己终于找对了方向，感到前方的道路虽然坎坷但一片光明．
唯一遗憾的是这时市面上关于开发.net应用中使用设计模式的图书还是不多，而JAVA那边从应用
框架到设计模式讲解的图书却是扑天盖到．小A这面感到茫然了，主要是感觉没有高人指点．下一步该
如何学习模式还是看些其实什么东西呢？
小A带着这样的疑问过了几个月，直到2004年初在市面上看到了<<程序员>>2003年合订本之后
才像找到了魂一样．因为在该合订本中，关于设计模式的讨论特别是在一个C++开源框架中使用设计
模式的分析中（请参见这篇文章），一个名字走入其视野，"马维达"先生用他点睛之笔，帮助研究和
使用ACE的C++同行们找到了学习ACE的方法，其所翻译的C++网络编程（1,2卷，候捷推荐）也成
为了那一年市面上少有的几本好书之一．接下来的日子里，小A因为有C++的一些基础（起码比JAVA
熟悉），开始了按书中所说内容在ACE框架海洋中畅游的"旅程"（也可能就是因为有了这块敲门砖，
才真正知道什么才是框架，以及满足面向行业应用而开发设计的框架应该是个什么样子）．
接下来整整两年的日子类似于苦行僧，一方面是模式学习，一边是框架学习．模式从创建型到结
构型再到行为型，框架逐步从ACE真正转移到.net下的框架. 与同事和朋友MSN,QQ上聊的也是NH-
ibernate，Ibatisnet,Spring.net, castle之类的.net框架，好在这时博客园也日渐热闹起来，也
开始有模式和框架学习的文章陆续发表．至今小A还记得最早在园子里看到的框架的文章就是"叶子的家"
发表的关于castle, 以及后来陆续出现的研究学习NHibernate，Ibatisnet，log4的文章．其实在一
开始实际用使用的是castle，主要是当时公司里对自己所在的开发小组在项目开发时间上不作严格要
求，所以小A就利用这一点，在一开始时将了解的castle方面的东东用到了项目中，而这次不成功的
使用才让小A了解到框架如果用的不是时机和场合，无论对开发人员还是公司而言都会很"痛苦"．
虽然Castle有非常好的各种特性，ActiveRecord，MonoRail, MicroKernel/Windsor等．且项目
本身虽然时间上充足一些，但如果使用Castle需要深入了解这个框架的人．而如果团队中无人知晓相关
信息，导致学习的成本偏高．另外就是当时使用"Webform+控件"方式开发的同事在公司还是主流，而
MONORAIL方式要求使用NVelocity，大家还要学习这种模版语法，所有不少人打了退膛骨，最终项目
只做了几天就还是回到了老路上．这次尝试以失败告终．但小A还是期待着与CASTLE再次重逢的日子．
另外通过框架来学习设计模式也是一个不错的选择，必定应用型框架本身要求模块化，可重用性和
可扩展性，简单性及可维护性．是开发人员思想的深度锤练．
注：说到了Castle，这里不得不聊些题外话了．因为这一年以来随着monorail与微软的MVC框架
关系越来越暧昧．导致一些朋友开始对monorail的前途感到迷盲．Hamilton Verissimo之前表示过如
果MVC正式版没有其所希望的那样（存在分歧），他会考虑继续monorail的后续开发．而随着其加入
微软之后，他本人的活动显然没有以前在CASTLE官方社区中那样活跃（大家可以看看那几年他的发帖
和回复量）．在MEF发了 CTP版之后一直没怎么看到其在讨论区活动．这与以前那个在开源社区中的
"活跃分子"形象相去甚远．而让我隐约感到不对劲的地方就是其在CASTLE上发过一篇加入微软日志，
从字里行间我没看出多少喜悦之情，倒是某种忧虑萦绕其中．也许他在忙于其在微软工作之后的首次
处女作MEF, 也许是忙于适应新的工作环境．起码其在微软的BLOG上至今仍没什么动静．
另外就是那几年(特别是2003-2004)是AOP和IOC流行的时候，那时如果哪个开源框架不支持这两种
流行元素就会成为"土豹子"．而这时看到的几篇文章至今仍让人记忆忧新，包括：
向依赖宣战----依赖倒置，控制反转和依赖注入辨析 作者：王泳武
动态代理的前世今生 作者：透明
AOP的本质和意义 作者:徐昊
动态代理的前世今生 作者：透明
AOP的本质和意义 作者:徐昊
而无论是spring.net和castle都提供了AOP的支持，而CASTLE中用的就是基于动态代理的Aspect#,
而这个AOP框架以Facility工具方式引入到CASTLE框架中．通过该方式还集成了IBatisNet，NHibernate，
Wcf等框架．
虽然在小A的实际开发中没有过多的应用框架来提升开发速度，但研究框架代码的确能够扩展程序员的
视野，提升自己的开发功力和解决问题的能力，还包括思考方式的转变．而真正提升开发速度的倒是Code
－Smith这类的代码生成工具．也许某些人不屑于使用这类工具，认为这是懒人而不是"真正程序员"的所为．
但什么东西也许真正用到才会感到其中的乐趣．因为之前小A已经从那家网站跳槽成功（就在那次失败的面
试后不久），而新公司所给的薪水也是前一家的两倍，但如果想将来买房置业的话，还是不够．这时小A开
始跟其他同事一样，业余时间接私活．并且时常要接1-2家的私活．因为平时只能用下班时间或周六日来干
这些零工，所以时间有限，而客户那边经常又催（甚至在小A上班时使用MSN就接上头了），所以不得不依
懒这些代码生成工具的帮助．并且因为CODESMITH支持模板机制，只要改动很少的代码就能完成定制并生
成自己想要的格式代码，且不会出错，所以这时感到这类工具的确是个好东西．
而这时对设计模式的使用也让小A从中受惠颇多，因为模式本身所讲求的即是灵活复用．小A也不失时
机的对已有的代码进行重构，提练归纳出来了一些代码，采用模式的方式对这些代码进行规划和设计而恰
恰是这些代码在日后开发中被不断的复用到别的项目中，减少了很大的工作量．比如说使用 抽象厂模式
所做的数据库链接类等．
其实这时小A也开始有意无意的注意.net这个框架的一些架构上面的内容，并开始着手考虑开发出一个
自己所处行业的框架．这时在网上看到这本叫做<<应用框架的设计与实现>>一书(之前从网上和书上所看
到的都是如何学习和使用框架的著作和文章)，而这本书恰恰是教你如何设计框架和使用设计模式搭建框架．
这是一个新的切入点，而通过这本书(虽不像那些经典著作那样高深)，的确帮助小A打开了一扇新门，看到
了更广阔的天地．小A不仅自己很快看完了该书，还尽力向同事和朋友推荐．必定好东西要大家共享呀!
这样在那家新公司又渡过了一年半左右的时光，虽然每天很累很忙但很充实．而这时小A也把在CSDN
上的blog搬到了cnblog上，不仅因为这是一片更大的舞台（此时博客园已经成为了国内.net开发人员最大
的社区），并且首页文章的含金量也相当高（信息的燥声要比今天小）．当然入住博客园之后将近半年的
时间小A都在潜水，这主要是因为小A感学自己水平有限且初来轧道，另一方面主要还是时间不够，平时浏
览学习园子里的文章就够喝上一壶的了．
在一年半之后，小A又通过朋友推荐去了一家技术实力更强且有较深厚行业背景的公司，而在这家公司
里面，小A才感受到了业务需求这个以前从未认真对待过的东东是如何左右开发流程的．也才真正认清业务
需求和技术之间的关系．因为之前小A感觉自己的发展方向应该是做软件架构，所以认为技术是第一的，其
他原因只是被放到其后，而那时身边的朋友也都是清一色的技术人员，大家平时谈的最多的也是技术内容．
而在一次MSN上与一个招收架构师的公司聊这个话题时，对方所说的一句话给小A留下了十分深刻的印象．
"架构师应该是面向行业的，换句话说架构师要了解其架构的软件所服务的行业，并能根据公司战略决
策来规划架构软件，使其为公司牟利．"
其实上面所说的部分内容的确被CSDN前一阵子所做的一个视频专访节目中提到过，大家感兴趣可以参
见这个链接：
与知名架构师 周爱民共话架构师程序人生
注：前阵子CSDN在上海搞了个＂英雄会＂，邀请了不少业内知名的CTO来参加，其中有些内容也非常
有代表性．
其实写到这里，大家应该能理解通过设计模式，代码生成工具等手段来提升开发火力这一结论了．而对
框架等内容的理解又可以扩展自己的视野和思考问题的角度，相当于增加了子弹的射程和精确性．所以这时
小A已完成了从手 枪转型为步枪．但事件还没有这样简单，因为正如上面所说，业务需求分析这时真正开始
引起小A的注意，所以这就引出来下一篇的内容，即：
小A是支枪，子弹未打光 之 狙击步枪（如下图）
我们将会在下文中，跟小A一起感受"业务需求"在实际开发中所扮演示的角色．并看到小A从一支步枪变成
一支狙击步枪的心路历程．
好了，今天的内容就先到这里了．有兴趣的朋友可以在回复中进行讨论．
tag:开发,webservice,soa,wcf,手 枪,步枪,castle,设计模式,framework
作者:代震军,daizhj
原文链接:http://www.cnblogs.com/daizhj/archive/2008/10/06/1291817.html
