2012年4月27日星期五

架构,改善程序复用性的设计~第一讲 系统的复用性离不开系统的面向对象性

架构,改善程序复用性的设计~第一讲 系统的复用性离不开系统的面向对象性

非常抱歉让大家等了这么久,这个系列的第一讲才开始,呵呵,目录写出来后,就是按着目录一个一个的讲出来,与大家一起分享我的开发经验了,呵呵。

今天主要说一下“系统的复用性离不开系统的面向对象性”,我们可能有一种感觉,那就是在开发一个项目时用到了一段代码块,在另一个项目中也用到了,我们通常的作法就是ctrl+C,然后ctrl+V,呵呵,这样做的好处就是省事,不好的地方也是“不省事”,为什么这样说呢?

省事:因为它不需要考虑什么,只是为了实现而去实现,而这肯定是不提倡这种方式的,因为使用这种方式编程的人,永远不会体会到其中的乐趣,可能只是为了工资而去工作。

不省事:在程序的测试阶段,工程师们突然发现了你复制的那块代码出现问题了,可能是性能问题,也可能是业务问题,也可能是。。。,反正是出问题了,那你作为一个负责的程序员,会怎么样,当然是一个一个的去改了,同样是ctrl+C,ctrl+V,但此时你的一定再后悔,不如把块代码,或者那个方法,再或者那个类,再或者那个项目给抽象了,呵呵。

 

今天我就来说一下系统要想得到复用,必须把系统先进行抽象,也就是你的系统代码要符合面向对象的特性,这个系列我将会用最近开发的“通用后台系统”做为实例,讲给大家

这个系统中,用到了4个解决方案文件夹,我下面来分别说一下它们

一 Project.Common文件夹:它为所有项目提供一个公用的,不依赖于其它项目的项目集合,如图:

image 

OnlinePayment:支付功能模块相关

Standard:服务端和端户端持久化相关

VCommons:公用功能类库相关

VConfig:全局公用配置信息相关

二 Project.Core文件夹:它是对N层模型的抽象,将Web(UI),Entity(Model),Data(DAL)等各层的核心公用代码抽象出来,形成一个与领域无关的项目集合,如图:

image

Data.Commons:对数据层的抽象,本例中使用了Linq To SQL做为底层ORM,它同样适用于Entity Frameworks

Entity.Commons:对实体层的抽象,本例中的实体全部是对linq to sql原生实体的扩展,这也多谢微软的partial关键字,并对实体赋值进行了跟踪

Web.Commons:对WEB层的抽象,本例是标准的MVC模式的风格,对controller进行了抽象,以极对公用特性的抽象,如登陆验证等

三 Common.Background文件夹:它是对标准的后台管理系统的抽象,包括最基础的后台基础,有对用户,菜单,权限,部门等模块的管理,它适用于所有后台项目,如图:

image

Common.Background.Data:对后台数据层的实现,它继承自Data.Commons

Common.Background.Entity:对后台实体层的实现,它继承自Entity.Commons

Common.Background.Service:后台业务层的实现,它处理最基础的业务逻辑

Common.Background.Web.Controllers:后台UI层的实现,它继承自Web.Commons

四 个性化项目文件夹,这个就是和领域有关的真正的项目了,它有自己的架构标准,如图

image

我们可以看到,它也是标准的三层架构,前台和后台公用Data和Entity层,项目比较简单,没有使用Service层。

通过一个真正项目的解说,您是否对如何提高程序的复用性有一个比较清晰的认识了呢?呵呵!


TAG: