[从架构到设计]第一回:设计,应该多一点

[从架构到设计]

第一回:设计,应该多一点

发布日期:2007.8.15 作者:Anytao

©2007 Anytao.com ,原创作品,转贴请注明作者和出处。

Anytao.com 

设计就像是转魔方,你必须面面俱到。 

1. 引言

anytao开始想尝试尝试写点设计的东西了,只所以有了这个“突如其来”的想法,原因其实很简单:因为对设计、架构、分层、模式,我很陌生。因为陌生,所以接触,因为接触,所以随笔。系列之构思就这么诞生了。因此,这个系列是个方法论,是个杂文集,也是个见证史。我不期望能收获多少掌声,但求能保持更多交流。作为技术的狂热追求者,我始终认为两件事情是技术的立命之本:

因为,你会发现在日新月异,纷繁复杂的技术领域里,一切都在变,一切都在赶,我们拼命的狂追,换来一片的豪赌。唯一不变的,一是底层,二是设计。所以我只关注这两个,也只关注这两个,这是我认为的学习方法论中的第一守则:确定不变的追求方向。

那么这个系列将关注些什么方向呢?

  • Architecture---架构
  • Method&Process---设计方法与设计过程
  • OO--面向对象
  • Design Pattern---设计模式
  • Learning Method---学习方法论

2. 从架构到设计

当年,petshop作为.NET和J2EE两个派别之争的产物,坐在了潮流的风口上,时间已然过去,当时硝烟早已消失。我们庆幸的是petshop一路走来,从1.0到4.0,综观其设计的脉搏,能够感受到架构的日渐成熟和演变,这是技术之争留给我们最大的看点。

 

(图片来源:MSDN)

从1.0的简单3层BS系统架构,到4.0实现较复杂的分层结构,同时引入数据缓存、异步处理机制,petshop成为典型的分层结构的代表为架构设计的学习提供了良好的资源与素材。从历史的遗迹中,我们挖掘到的是什么?

  • 思想:分层架构,3层也好,7层也罢。根据的是具体的系统需求而定,但是基本的表示层、业务逻辑层和数据访问层的有机划分,是一种导向。而由分层带来的性能影响,可以通过数据缓存、异步处理机制来弥补。
  • 方法:模式就是方法,petshop中就不乏模式的大量应用与技巧,抽象工厂模式完成对象创建;策略模式封装业务行为。
  • 策略:面向接口的设计,剥离了层与层之间的强耦合,使得各个模块保持相对的独立性,体现了封装变化的基本思想。
  • 技巧:表现层中以masterpage来实现对页面的控制,既省时又省力。
  • 缺陷:没有应用ORM,数据和实体的分离不够彻底。希望在5.0中有更好的方案。

没有一成不变的设计,也没有一成不变的架构。方案是永远随着需求,随着技术而不断重构,设计之美就体现在不断的否定与自我否定中。本系列不是讨论petshop的专题,这方面的讨论已经很多了,我们没有必要再造轮子。因此,更关注如何,怎样和思想,是这里的讨论。

那么,设计、架构应该从哪儿入手,又如何进行?面向对象的原则又是什么?设计模式又如何融入到我们的架构体系中?这一系列的问题,我想说可能根本没有答案,而确有方法。本系列就力图从方法的角度入手,以并非专业又并非经验的视角来阐释如何以菜鸟的立场来“空谈”设计。因为,你不能说设计只是架构师的事儿,否则满篇的代码又如何体现艺术之美呢?作为菜鸟, 我们少了经验,但是多了思考,因此对架构、对设计、对模式的探索,应该从一定的方法做起,这是本文和本系列试图达到的目标。

作者力图以例小心求证设计,以图来大胆阐释方法。例如,软件设计的分离点应该如何来考虑呢?

Anytao.com 

  • 首先,分层思想是从职责角度对架构进行了约束,表现层、逻辑层、数据层各负其责,层与层之间以接口进行信息交互,减少耦合度。
  • 其次,框架和通用组件则是从通用性角度提高了系统复用并减少耦合度,例如,在一个应用系统中,.NET Framework是技术通用组件,提供了系统开发数以千万计类,而系统中的进度控制、消息控制和异常处理可以开发为专用的模块,作为领域通用组件,然后在此基础上再实现具体的业务需求。
  • 最后,模块化思想则是从功能点对系统进行了分离与封装。一个大型的系统,一定是分成多个功能模块进行的开发,每个子模块甚至也有必要进行架构设计和粒度划分,这主要依赖与其在系统中的复杂度和重要度。核心的子系统设计,最好落实到具体的类设计,对粒度的把握也是架构设计值得思考的话题。

分层角度,框架基础,功能划分,一个系统设计要综合考虑这些因素。可能还不止这些,也可能只是其中的一点,具体的架构要看具体的需求。然而探求架构和设计方法的时候,我们要把握基本的方法和思路去迎合前人总结的经验,也叫科学。

以上述思路来回顾petshop 4.0的架构,我们很明显的感受到,良好的设计正是巧妙的耦合了架构设计中的诸多因素,提出了近乎完美的方案。分层角度来看,在petshop中自不必说,明显的三层架构体现了良好的系统分离与耦合;通用角度来看,.NET Framework作为技术通用组件,提供了系统实现的基本技术基础,而对Profile和Membership的分离,则体现了领域通用部分的价值;模块角度来看,由于petshop本身的业务需求比较简单,因此模块划分不够明显,但是对Order的处理可以看作简单的业务模块了。而其他方面,例如设计模式,面向接口开发的技术,也同样体现在petshop的大框架中,让我们受益非浅。 

3. 结论

从架构到设计,漫游在一个技术而艺术的世界,一直是我的梦想。对技术的驾驭,不是看你了解多少细节,更重要是你控制了多少格局。架构设计就是一个控制格局的艺术,只有游刃有余的驾驭了如何将技术细节变成就轻驾熟的应用,才是设计的最高境界。届时,你会发现,原来技术可以更美的。所以,我要说,设计,应该多一点。

 

 

 

参考文献

(中国)温昱,软件架构设计

(USA)Geoffrey James,The Tao of Programming 

[公告]

【CLR团队公告】活动公告、邀请函团队纲领

【系列公告】你必须知道的.NET从架构到设计

 

温故知新

©2007 Anytao.com

原创作品,转贴请注明作者和出处,留此信息。

本贴子以“现状”提供且没有任何担保,同时也没有授予任何权利。
This posting is provided "AS IS" with no warranties, and confers no rights.

posted @ 2007-08-15 23:11 Anytao 阅读(7009) 评论(51)  编辑 收藏 所属分类: F Design&Pattern

  回复  引用  查看    
#1楼 2007-08-16 00:12 | 赤裸小绵羊      
架构,说起来容易,做起来谈何容易啊!
  回复  引用  查看    
#2楼 2007-08-16 01:16 | Anders Cui      
“唯一不变的,一是底层,二是设计。”
不太同意,底层的细节和设计的思想都在变化
但细节要比思想变化要快得多
如果我们学习设计模式,可以看一些Java方面的书
但如果要学习.NET Framework,那就只能看.NET的书了
所以我们应该选择一个大体的范围(开发的平台、语言等)
在此前提下,底层的变化便缓和多了
  回复  引用  查看    
#3楼 2007-08-16 06:09 | 五年      
最后那个图不错
  回复  引用  查看    
#4楼 2007-08-16 06:27 | 金色海洋(jyk)      
挺厉害,。
  回复  引用  查看    
#5楼 2007-08-16 07:05 | 布尔      
只有运势而变才能永葆青春,呵呵
  回复  引用  查看    
#6楼 [楼主]2007-08-16 08:45 | Anytao      
@赤裸小绵羊
很有同感,需要不断的捉摸。。。
  回复  引用  查看    
#7楼 [楼主]2007-08-16 08:48 | Anytao      
@Anders Cui
您的意见很对,.NET不是也每几年一次的变革再发展吗?但是我认为实际底层的东西从1.0到3.0都是一脉相承的,虽有变,但有恒。设计与架构就更不用说,设计思想也在不断的发展,我们要把握的是其不变的思想。
  回复  引用  查看    
#8楼 [楼主]2007-08-16 08:49 | Anytao      
@五年
@金色海洋(jyk)
@布尔
:-)
  回复  引用  查看    
#9楼 2007-08-16 09:23 | Anders Liu      
支持啊!又出力作!
  回复  引用  查看    
#10楼 [楼主]2007-08-16 09:28 | Anytao      
@Anders Liu
呵呵, 突然有点感觉就写了, 还不知道这个系列怎么发展, 看感觉吧. 不过.NET系列还是会作为重点继续坚持。
也很期待你的好文。
  回复  引用  查看    
#11楼 2007-08-16 09:31 | beyondjay      
不过我决得pershop的BLL层太简单了,感觉非常单薄,希望以后的能展现复杂业务逻辑的BLL实现。BLL里也有很多技巧能用吧,petshop的很多模式现在只是用在数据处理层面。
  回复  引用  查看    
#12楼 2007-08-16 09:54 | Anders小明      
关于你的那个软件设计分离点的图,实际上那个通用的点很孤立的,和其它两点根本不是一个概念的分解结构。

我会把这个点去掉,换成抽象分层角度;同时把分层角度重新命名为行为分层角度。系统越大,抽象分层是必不可少的!
  回复  引用  查看    
#13楼 2007-08-16 10:07 | Reeezak      
文字很不错,文章也很不错^_^

不过,对于一个真正的项目来说,需求才是最重要的,设计可能需要修改的,哪怕你的业务层设计得在漂亮,仍然免不了大的改动,也许会有人说架构设计好了就不会有问题!也对!不过,谁又能保证自己设计的架构就万无一失呢?

另外,对于ORM的观点不敢苟同,任何东西的使用还是要看实际情况的,一味的使用是没有好结果的。
  回复  引用  查看    
#14楼 [楼主]2007-08-16 10:31 | Anytao      
@beyondjay
的确如此,petshop的BLL层略显简陋,不过重要是如何组织层与层之间的分离与交互,这是应该关注的热点。
  回复  引用  查看    
#15楼 [楼主]2007-08-16 10:35 | Anytao      
@Anders小明
呵呵。
其实你所指的抽象分离,某种程度上就是将通用与专用分离吧。我认为大型系统出了有高度抽象的分离,也要关注通用组件的分离,这点上应该不矛盾。按行为分层,值得思考。谢谢。
  回复  引用  查看    
#16楼 [楼主]2007-08-16 10:37 | Anytao      
@Reeezak
良好的设计,就必须关注变化、扩展,否则根本称不上设计。所以设计之要就应该将可扩展,可分离的东西重点考虑。
需求总是在变,设计需要的就是在减少改变的原则下进行柔性适应。
  回复  引用  查看    
#17楼 2007-08-16 10:48 | Anders06      
Up, 期待后作
  回复  引用  查看    
#18楼 [楼主]2007-08-16 10:58 | Anytao      
@Anders06
有压力了,不过还是想自由自在写。接下来想先从面向对象说起。
  回复  引用  查看    
#19楼 2007-08-16 11:08 | 周银辉      
期待此类文章
  回复  引用  查看    
#20楼 [楼主]2007-08-16 11:23 | Anytao      
@周银辉
:-),继续努力吧。
  回复  引用  查看    
#21楼 2007-08-16 11:31 | Reeezak      
@Anytao

BEGIN QUOTE
良好的设计,就必须关注变化、扩展,否则根本称不上设计。所以设计之要就应该将可扩展,可分离的东西重点考虑。
需求总是在变,设计需要的就是在减少改变的原则下进行柔性适应。
END QUOTE

说得不错!不过博主应该是误解了我的意思,我是说对于一个应用来说,我们应该更加关注其需求,而不是一开始就绞尽脑汁的弄一个所谓拥有好的扩展性的框架出来,特别是对于小企业,因为这样的框架基本上不可能是达到预期要求的,比如PETSHOP或PETSTORE从它们最初的版本走来,也是经历了很多次大的修改。

而且,不是什么应用都能使用同一个框架的,所以,对于这一点来讲,我觉得更多的还是应该关注需求。

当然了,仅仅从技术上来讲,拥有一个好的设计当然比一开始就编码要好^_^
  回复  引用    
#22楼 2007-08-16 11:44 | 阿毅 [未注册用户]
个人愚见:
要想成为好的架构师,还是要学好哲学,锻炼洞察力,能看清本质、权衡利害轻重才有协调的前提,思维能在技术细节和系统化理念之间自由穿行。
单个技术难点总是能解决的,而将技术的难点系列化归纳出一套方式方法,使其变得稳定易控制就不简单了。
良好架构下的设计总是需要适度的预见性,至少必须是容易重构的。
只是何为适度?道理只有那么几句话,可真要判断却很难。
还有一个事实,完美的架构未必是当下可行的,我想只有承认并依照事物多曲线交叠发展规律进行工作才不会误入歧途。

也许一段代码看的是数学好不好,而一个设计则可能看的是哲学如何。
  回复  引用  查看    
#23楼 2007-08-16 12:38 | 翔翼      
感兴趣的文章,目前也在考虑同样的问题,不过还很粗浅。
文字很不错,加油!
  回复  引用  查看    
#24楼 [楼主]2007-08-16 13:12 | Anytao      
@Reeezak
很有同感,在公司我们的作法也是首先关注于需求,再突破与设计。不过,这既是软件工程的范畴了,谢谢你的想法。
  回复  引用  查看    
#25楼 [楼主]2007-08-16 13:17 | Anytao      
@阿毅
建筑师是以水泥认识世界的,架构师是以代码认识世界的。上升到高度,就是一种抽象,这可能就是哲学了。看问题,用方法,就是哲学范畴。所以,我觉得建筑也罢,软件也罢,都是有方法的。我们只期望用一定的方法了减少这种认识观的形成距离。
  回复  引用  查看    
#26楼 [楼主]2007-08-16 13:18 | Anytao      
@翔翼
其实我的认识也一样,大胆写了点,期望做的更好,共同进步。学习是永无止境的。
  回复  引用  查看    
#27楼 2007-08-16 15:46 | 刘荣华      
LZ又出力作,支持一个:)。

关于架构,设计,怎么讲呢。有的时候发现设计的时候会受所谓的业务逻辑这种概念影响。其实从实现角度来讲。无外乎是一些功能:数据库处理、文件处理、通信处理、硬件交互、等等。
所谓我们平常设计时讲的底层,我认为应该要指这些系统最通用的零部件。这些东西能组成我们需要的框架。
用任何语言和技术手段都能实现这些框架。呵呵,但是用汇编和用C#来实现同样的功能付出的成本又是不一样的。
LZ这个图画的很好。很精辟啊。
好的框架应该是追求的目标。而不能成为束缚自己设计的理由。任何事物都不可能有完美的。



  回复  引用  查看    
#28楼 2007-08-16 16:44 | temptation      
支持 !

期待下文 !
  回复  引用  查看    
#29楼 [楼主]2007-08-16 17:18 | Anytao      
@刘荣华
呵呵,谦虚了,你的作品是我最爱品味的好文。
设计之难,就是因为要在多个纬度上考虑究竟,那个图表达的就是这个意思。
  回复  引用  查看    
#30楼 [楼主]2007-08-16 17:18 | Anytao      
@temptation
:-)
  回复  引用  查看    
#31楼 2007-08-16 18:28 | flyingchen      
似乎好多设计方面的书(甚至包括国外的)都是引用孔孟语录,道家思想开头,呵呵
所以同意阿毅所说的,要学哲学。
抽象的本质也就是对问题本质的提炼嘛,而哲学正好是关注这个方面的
  回复  引用  查看    
#32楼 [楼主]2007-08-16 21:59 | Anytao      
@flyingchen
很有同感,异曲同工。
好久没有你的动向,很忙吧:-)
  回复  引用    
#33楼 2007-08-16 23:31 | kisskiki [未注册用户]
架构,设计这些个东西关键还是一个悟字,学哲学只不过是通过其他的途径进行突破罢了。学不学哲学对于学习好架构,设计并没有因果必然关系。

楼主的文笔看来又上了一层楼了,开卷果然有益啊。





  回复  引用  查看    
#34楼 [楼主]2007-08-17 00:17 | Anytao      
@kisskiki
呵呵,谢谢。
悟。似乎都有道理。
  回复  引用    
#35楼 2007-08-21 09:58 | 温昱 [未注册用户]
写得不错!
  回复  引用  查看    
#36楼 [楼主]2007-08-21 11:02 | Anytao      
@温昱
呵呵,谢谢,你的那本书让我成长不少。算是国内少有的精品了。
  回复  引用  查看    
#37楼 [楼主]2007-08-29 00:20 | Anytao      
@释心
:-)
  回复  引用    
#38楼 2007-09-01 12:19 | .NET开发技术 [未注册用户]
您好!我在博客圆网站上看到了您发表的系列关于.NET技术的文章,深受启发。我们几个看了您所写的文章的.NET同行都非常佩服您的才华,想和您一起探讨.NET技术!
大家都非常期待您的加盟!.NET技术交流群:12339353
  回复  引用  查看    
#39楼 [楼主]2007-09-03 19:39 | Anytao      
@.NET开发技术
很高兴认识你,技术共享,责无旁贷。
  回复  引用  查看    
#40楼 2007-09-07 13:36 | 博览群书      
在架构方面才刚刚开始,仅仅有个概念,不过做程序也有几年了,对博主的想法很赞同,追求永恒不变的东西,才是正道。人的时间有限。

  回复  引用  查看    
#41楼 [楼主]2007-09-12 19:42 | Anytao      
@博览群书
呵呵,有机会切磋切磋。
  回复  引用  查看    
#42楼 2007-11-08 00:35 | 随风逝去      
学习!
  回复  引用  查看    
#43楼 [楼主]2007-11-08 09:35 | Anytao      
@随风逝去
呵呵,你来了,:-)
  回复  引用    
#44楼 2007-12-13 23:53 | 嘟嘟嘟嘟 [未注册用户]
哈哈,楼主能不能顺带做个petshop4.0的专题呢????期待!
  回复  引用  查看    
#45楼 [楼主]2007-12-14 00:03 | Anytao      
@嘟嘟嘟嘟
嘿嘿,曾经很早有这个打算,后来忙于CLR的研究就搁置了,最近也比较忙:-),所以暂时还没有这个打算,不过我推荐你拜读一下Bruce Zhang关于Petshop的几篇经典文章,他的描述已经够好了,相信会给你带来收获:-)
  回复  引用    
#46楼 2007-12-14 10:06 | @嘟嘟嘟嘟 [未注册用户]
Anytao

谢谢啦,期待你的新作。

现在就去拜读你的推荐大作。。。哈哈哈
  回复  引用  查看    
#47楼 [楼主]2007-12-14 11:50 | Anytao      
@@嘟嘟嘟嘟
:-)
系列还在继续,更多内容敬请关注》
  回复  引用  查看    
#48楼 2008-04-22 12:45 | 镜涛      
架构设计不是说要设计就能设计出来的,需要从实践中积累,只有做得多了,写得多了才能够知道在那些模块上怎样设计能够具有扩展性,能够经得住变化的洗礼。模式可以应用于系统的某些模块以解决某些特定问题。大的分层可以因为足够抽象而保持不变例如经典的三层结构。不过拿到具体的某个层,就需要根据需求仔细定制了。呵呵,个人感觉是这样子的 。
  回复  引用  查看    
#49楼 [楼主]2008-04-22 23:22 | Anytao      
@镜涛
呵呵,言之有理,这个系列也正是想通过一系列的过程记录,将我在项目中的体会和经验做以分享,没有绝对的对错,更多的是需要倾听其他高手的建议和讨论。架构没有最好之说,设计没有标准之路,我们只能力求做得更好。

欢迎经常讨论:-)

标题  
姓名  
主页
Email (只有博主才能看到) 
验证码 *  看不清,换一张 [登录][注册]
内容(请不要发表任何与政治相关的内容)  
  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      
该文被作者在 2007-08-15 23:28 编辑过


相关链接: