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

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

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

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

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

 

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

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

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

 

OnlinePayment:支付功能模块相关

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

VCommons：公用功能类库相关

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

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

Data.Commons：对数据层的抽象，本例中使用了Linq To SQL做为底层ＯＲＭ，它同样适用于Entity Frameworks

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

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

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

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

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

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

Common.Background.Web.Controllers：后台ＵＩ层的实现，它继承自Web.Commons

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

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

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