UML系统分析与设计04-架构设计之“分层”

我不是一个架构师,写下这些内容也仅作为个人的一点总结,以作抛砖引玉之用。 平常在谈论系统架构时,我们常常会听到类似“三层架构”、“多层架构”的说活,但是在严格

  我不是一个架构师,写下这些内容也仅作为个人的一点总结,以作抛砖引玉之用。

 

  平常在谈论系统架构时,我们常常会听到类似“三层架构”、“多层架构”的说活,但是在严格的UML设计却并没有直接的对于“层”的形象描述;在典型的基于“4+1视图”的架构设计文档中也同样没有明确要求对“层”的形象分析。

  [注意:喜欢“层”的朋友,在4+1视图时可在逻辑视图中单独添加对“层”的详细说明]

  在基于UML设计时,我们往往会把“分层”的理念分解成“组件”和“包”的形式来展现,但作为一名.net开发人员来说,对于“层”的喜爱却是由来已久,且其直观的表观方式也是无法替代的,就我个人而言非常喜欢使用。以往,我常用PPT来绘制这部分的内容,自从VS2010后,就可以统一到一处了。

 

一、PetShop分层架构图

  如果您是一个从业多年的.net程序员,那么对PetShop的历史应该是稍有了解的,自PetShop2.0开始,每升级一次都会伴随着一个典型“分层架构图”,我就是从那个时候起开始喜欢上“分层架构图”的。

  PetShop 2.0分层架构图

   

 

  PetShop 3.0分层架构图

   

 

  PetShop 4.0分层架构图

   

 

 

二、NLayer分层架构图

  NLayer作为微软公布的又一个典型的.net技术解决方案,在分层架构上让人耳目一新,当然看源代码(解决方案)来理解分层架构可能会比这个给出的架构图更明了,或者说本可以提供一个更详细“分层架构图”。

  也许是NLayer给出的分层架构图,其主要目的是为了展示.net强大的技术体系(正如说明中的“Mapping Technologies”)而非介绍架构思想。但无论如何我们不得不说NLayer在分层上做的还是相当不错,有较强的代表性。

  对NLayer项目感兴趣的朋友可以从http://microsoftnlayerapp.codeplex.com/ 了解更多详情。

  以下是这个项目的“多层架构图”:

   

 

三、另一种风格的基于分层架构图

  曾经在CSDN论坛上看到有人提了个分层架构的问题,其中就引用了如下的一个分层架构图,后经查实其实出自于:http://www.cnblogs.com/ssol/archive/2011/09/14/2175320.html,据我个人分析,这也不愧为一个典型的分层架构图。

   

  

四、Visual Studio对分层的支持

  虽说“分层”的做法由来已久,但真正在IDE中得以很好的支持,却是始于VS2010。在VS2010架构师版中不仅提供了对UML的支持(并非完全),同时也加入了自己 “分层”的理念。同时对于一些典型的架构模式,也提供了基于Visual Studio的插件,以方便设计人员能快速、简单的绘制分层架构图。基于VS2010和VS2012插件可以分别通过以下两个地址进行下载并安装。

  For VS2010:http://visualstudiogallery.msdn.microsoft.com/9c8051f8-e8f7-45b1-8d04-dad6afc697d2

  For VS2012:http://visualstudiogallery.msdn.microsoft.com/94ca6b70-539c-4f49-98c9-0550a4c044bf

 

  以下是安装插件后,分别从VS2010和2012RC上的截图。

  1、  VS2010架构模板

   

  

  2、  VS2010 Mobile Application

   

 

  3、  VS2010 Rich Client Application

   

 

  4、  VS2010 Rich Internet Application

   

 

  5、  VS2010 Services Application

   

 

  6、  VS2010 Web Application

   

 

  7、  VS2012RC 架构模板

   

 

  8、  VS2012RC Common Application Pattern

   

 

  9、  VS2012RC Service Archetype Pattern

   

  

  上述那些分层架构模板都是基于“最佳实践”的总结,具有很强的代表性。对于一些中小系统都可以直接拿过来用,或稍加修改即可。当然要完全明白各层的含义和作用,建议有兴趣的朋友可以参阅一下《Microsoft Application Architecture Guide, 2nd Edition》

   

http://msdn.microsoft.com/en-us/library/dd673617.aspxhttp://apparchguide.codeplex.com/

         

五、DIY一个Music Store的分层架构图

  由于我们一直采用的CodePlxe中MusicStore其初衷主要用于说明和演练Asp.net mvc技术,所以为了更好的说明架构和分层,我们人为地对其需求进行一定的扩展。

  1、  MusicStore是一个基于B/S和C/S混合模式的系统。

  2、  MusicStore是一个分布式系统,以支持加盟方式。且各加盟店内部使用C/S方式进行数据管理,以提供更好的用户体验。(当然B/S且有同样的功能)

  3、  MusicStore项目需要支持手持设备对唱片进行终端数据管理(如:定期对唱片进行检查,以确认丢失或损坏),核实信息是以无线的方式与PC进行交互。

  4、  可以通过GIS信息查找附件的唱片店。

  5、  可以打印用户自定义的报表或图表。

  (汗!假设的是不是有点过了?)

 

   接下来我们就简单地来为这些需求设计一个分层架构图:

  1、分层架构图

   

 

  2、简要说明

  Business Layer 为基于C/S和B/S模式应用提供统一的分布式应用服务,其中WinForm Presentation Layer 和WEB Presentation Layer都将采用WCF技术与Business Layer通讯。

  富客户端方面,采用WinForm方式进行UI设计,同时引进第三方DeVExpress控件库进行美化;为了能较好的实现单元测试,采用MVP模式进行实现。

  WEB方面,前台采用ExtJS脚本库,并采用ASP .NET MVC 3作为实现主框架。

  业务逻辑层主要基于领域服务来实现,并通过统一的封装为各客户端提供应用服务。本系统中采用DDD方式设计,DomainEntity作为各层间主要对象传输。

  仓储层主要采用MS SqlServer来为较大的连锁店供数据服务,当然也可以采用基于MS Access来为单个店面提供数据服务。仓储层采用Adapter设计模式以支持不同数据库系统,并接合IOC来进行动态配置。同时,对于基于SqlServer数据库系统的实现采用Asp.net Entity Framework技术实现;对基于Access数据库系统的采用ADO .NET技术实现。

  其中公共部分:通讯服务、GIS服务和Report服务为独立子系统,其具体实现可以独立分层和设计,此处不做详述。Security为系统提供安全;MSEL为微软件企业库,可以提供IOC框架、缓存机制、基于ADO .NET的数据库访问操作、异常处理、UI验证等;NLog为本系统的提供日志管理框架。

 

六、分层架构图的主要作用

  不管一个系统有多么复杂,如果最后形成了循环引用,那么基本上可以断定是因为在设计时分层没有做好。分层架构的好处不作多说,我们只说说“分层架构图”的主要作用。

  1、虽说UML定义为统一建模语言,但在其实操作和讲解上,其理论与技术实现还是需要一定的语言基础。相对UML来说,“分层架构图”就显得更加随和一些,对于一些特定客户,“分层架构图”在阐述技术方向、系统运作、应对变化等方面却有独到之处。

  2、“分层架构图”简洁明了的表现形式不仅能给非技术人员一目了然的感觉。对于技术人员也有一种高屋建瓴,拨云见日的感觉,使得开发人员能立即明白架构师的主要意图和思想。

  3、“分层架构图”首先能直观的描述系统的主要子系统、主要组件及其关系,为后继UML中“组件图和包图”的划分提供指导。

  4、在形成“分层架构图”时,架构师往往还需要分析出要使用哪些公共组件模块,有些模块可能现在不存在,但在本项目实施后可形成。有些可能已经有的存在,可直接使用。公共组件的积累也往往会伴随一个公司软件开发的成长,好的组件设计和成果也是公司的一项重要财富。

 

七、分层架构图的大同小异

  曾经在参加一个评审时,有人问到:“你的这个分层架构图怎么和微软件提供的模板看上去大同小异?” 其实确实如此!在我们的身边并不是所有的项目都是大项目、都是战略性的,在架构设计上要有独到之处,以解决复杂的需求和性能要求。而大部分的项目则是一些中小型的应用系统、甚至还有一些是用于“科研”的小程序,对于这部分项目我们完全可以借用比较常见的分层架构模板来完成,以节约设计时间。由于这些模板是基于实践的总结,其总体思想、思路、解决方案都比较成熟,也就是从宏观上来说就是“三层到多层”的通用解决方案,即大同!而小异则是基于项目本身的特点于细节处的区别,做到具体问题具体分析。比如我们可以采用WebForm的方式也可以采用ASP .NET MVC的方式作为表现层的实现方式;可以采用SqlServer 2005,也可以采用Oracol 10g作为数据库系统;同样的我们可以跟据项目的部署情况决定采用“贫血模式”或“充血模式”,这就不能一概而论了。