今天要和大家说的是动易sitefactory 的系统架构设计。
在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或成为领域层)、表示层,如图所示:
图一:三层的分层式结构
数据访问层:有时候也称为是持久层,其功能主要是负责数据库的访问。简单的说法就是实现对数据表的select,insert,update,delete的操作。如果要加入orm的元素,那么就会包括对象和数据表之间的mapping,以及对象实体的持久化。
业务逻辑层:是整个系统的核心,它与这个系统的业务(领域)有关。如果涉及到数据库的访问,则调用数据访问层。
表示层:是系统的ui部分,负责使用者与整个系统的交互。在这一层中,理想的状态是不应包括系统的业务逻辑。表示层中的逻辑代码,仅与界面元素有关。在动易cms 2007中,是利用asp.net来设计的,因此包含了许多web控件和相关逻辑。
分层式结构究竟其优势何在?概括来说,分层式设计可以达至如下目的:分散关注、松散耦合、逻辑复用、标准定义。
1、分散关注:开发人员可以只关注整个结构中的其中某一层;
2、松散耦合:可以很容易的用新的实现来替换原有层次的实现;可以降低层与层之间的依赖;
3、逻辑复用:可以有利于各层逻辑的复用。比如,可以使用同一个业务逻辑来实现不同的表现层,针对不同的客户端显示不同的界面。比如针对电脑和手机编写不同的界面,两者共用相同的业务逻辑。
4、有利于标准化;
一个好的分层式结构,可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口,负责不同逻辑设计的开发人员就可以分散关注,齐头并进。例如ui人员只需考虑用户界面的体验与操作,领域的设计人员可以仅关注业务逻辑的设计,而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认,开发进度就可以迅速的提高。
松散耦合的好处是显而易见的。如果一个系统没有分层,那么各自的逻辑都紧紧纠缠在一起,彼此间相互依赖,谁都是不可替换的。一旦发生改变,则牵一发而动全身,对项目的影响极为严重。降低层与层间的依赖性,既可以良好地保证未来的可扩展,在复用性上也是优势明显。每个功能模块一旦定义好统一的接口,就可以被各个模块所调用,而不用为相同的功能进行重复地开发。
进行好的分层式结构设计,标准也是必不可少的。只有在一定程度的标准化基础上,这个系统才是可扩展的,可替换的。而层与层之间的通信也必然保证了接口的标准化。
对于网站管理系统来说,采用分层式的设计,可以适应各种网站规模。网站的发展规模不断发展变化,从一个个人网站发展成大型门户网站,采用分层设计的系统自始至终都可以满足功能需求和性能需求。在网站早期,使用分层设计的程序可能会有些浪费,并且带来性能上的一些损失,但随着网站的不断发展,分层设计的程序可以不做任何修改或者只需少量修改即可满足大型网站的要求。而没有分层设计的程序,初期可能速度会较快,但网站一大,就不得不换程序,或者重新设计系统架构。
“金无足赤,人无完人”,分层式结构也不可避免具有一些缺陷:
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。这是对于程序员来说的,普通用户可以不用关心这一点。
在.net中,标准的bs分层式结构如下图所示:
图二:.net中标准的bs分层式结构
动易cms 2007遵循分层设计的思想,采用了三层设计的系统架构。系统架构图如下所示:
图三:动易cms 2007的体系架构
熟悉企业应用开发的网友可能会发现,动易cms 2007的系统架构图与petshop极为类似。是的,这是因为动易cms 2007的系统架构主要是参考微软的企业级应用范例——petshop4.0而设计的。
下面主要讲一下数据访问层(dal)和业务逻辑层(bll)的设计。
在数据访问层(dal)中,采用dal interface抽象出数据访问逻辑,并以dal factory作为数据访问层对象的工厂模块。对于dal interface而言,分别有支持ms-sql的sql server dal和支持oracle的oracle dal具体实现。而model模块则包含了数据实体对象。其详细的模块结构图如下所示:
图四:数据访问层的模块结构图
在数据访问层中,完全采用了“面向接口编程”思想。抽象出来的idal模块,脱离了与具体数据库的依赖,从而使得整个数据访问层利于数据库迁移。dalfactory模块专门管理dal对象的创建,便于业务逻辑层访问。sqlserverdal和oracledal模块均实现idal模块的接口,其中包含的逻辑就是对数据库的select,insert,update和delete操作。因为数据库类型的不同,对数据库的操作也有所不同,代码也会因此有所区别。
此外,抽象出来的idal模块,除了解除了向下的依赖之外,对于其上的业务逻辑层,同样仅存在弱依赖关系,如下图所示:
图五:业务逻辑层的模块结构图
图五中bll是业务逻辑层的核心模块,它包含了整个系统的核心业务。在业务逻辑层中,不能直接访问数据库,而必须通过数据访问层。注意图中对数据访问业务的调用,是通过接口模块idal来完成的。既然与具体的数据访问逻辑无关,则层与层之间的关系就是松散耦合的。如果此时需要修改数据访问层的具体实现,只要不涉及到idal的接口定义,那么业务逻辑层就不会受到任何影响。毕竟,具体实现的sqlserverdal和oracaldal根本就与业务逻辑层没有半点关系。
动易sitefactory 的业务层设计遵循这样一个原则:在业务逻辑的处理中,如果存在业务操作的多样化,或者是今后可能的变化,均应利用抽象的原理,或者使用接口,或者使用抽象类,从而脱离对具体业务的依赖。
动易sitefactory 与petshop的不同之处在于:petshop只是一个简单的应用范例,业务逻辑非常少,所以整个系统架构中,将所有的业务逻辑存放于一个bll的类库中;而整个动易系统是由多个产品模块的组合,所以实际上动易cms 2007的每个产品是遵循三层设计,然后再由这些产品组合成整个系统。这一个问题,我会在下一篇文章中讲到。