系统内部模块(子系统)之间的耦合以及模块(子系统)划分

  题外话

  最近已经在努力学习了,学习基本功,学习设计模式,学习成熟框架,学习软件架构。发现越是学习的多,越是发现自己知道的少。

  

  引言

  本篇中的系统使用的技术背景是:.NET平台,C#语言,数据库是SQL Server,其他平台没有参与过,所以没有验证过。

  简写解释

  BA,Business Access,业务访问

  DA,Data Access,数据访问

  Entity,实体

  Service Layer,服务层

  Order,订单

  Product,商品

  正文

  做系统大多时候会用到分层,不管是跟随流行趋势还是自己已经搞明白了分层的好处。大多时候就分割为:Entity, DAL(Data Access Layer), BAL(Business Access Layer)。

  在VS中就产生了下面的项目结构。

  

系统内部模块(子系统)之间的耦合以及模块(子系统)划分
  有的时候如果需要的话,可能还会有个Service Layer,提供更加粗粒度的服务访问,有时候也是为了方便其他系统调用,也为了隔离,提高安全性,屏蔽实现的细节。一个服务调用下去,可能会有多个BA在后面协调运作。

 

  对了还要加上一个Common类库,肯定会有一些基类、自定义异常、Cross-Cutting跨层的关注点、公用的方法、自定义常量,反正公用的都可以放在里面。

  

系统内部模块(子系统)之间的耦合以及模块(子系统)划分
  

 

  然后大家就开始分工了,可以按照模块,也就是功能,有人写Order相关的,有人写Product相关的。但是我认为这么划分不太好,有以下几点为证,以订单模块为例:

  1、一个人需要写订单操作的存储过程,然后写实体,然后写DA、BA,从底层写到UI,需要熟悉多方面的知识,每个层面的知识都要学习,但是时间紧、精力不足,造成每个层面都学的不是很精,写出来的代码也就不是太好,反正倒是能跑。有两个缺点:对个人来说,不利于发展,没有特长,哪里都不精通;对公司来说,个人没有特长,其实就意味着公司没有特点,前途的话,可想而知。

  2、就算完成了,拿DA来说,每个模块都需要DA,但是每个人写的习惯不一样,你用ADO.NET,我用Entlib,我用NH。。。。,而且就算用ADO.NET也不一样,造成后面的维护的升级有很大的困难,维护周期会加长。而且不利于优化,因为写法不统一,就算优化,也需要更多的时间来统一;而且由于上面的一点,没有人对数据访问精通,所以也没有办法优化了。

  那就按层来划分吧,你写DA,我写BA,还有人写Service。写之前,先定义层之间的接口,接口定义好了,自动化测试工程师,还可以写自动化测试脚本,然后每个人写自己一层的具体实现。针对接口编程,不针对实现编程。哈哈,用在这里了。

  项目组终于有了较为正确的开发方式。过了一段时间,V1.0出来了,大家都很高兴。但是后期肯定会有变化吗,软件吗,不变化也就代表没有生命力,没有生命力,肯定会完蛋,完蛋了,我们也就失业了,需要换个地方从头来过了。

  好的,变化来了,比如说订单部分有逻辑需要修改,甚至改动较大,工期大概2个星期。商品部分也有bug,但是2天就可以了。假设改动都在BA。

  过了两天,商品的bug修改完毕,想要测试一下。但是由于order的还没有修改完毕,所以BA整个编译通不过,所以UI没有办法测试,自动化也没有办法测试,因为需要引用BA程序集,但是BA编译不过。只好等了,一等就是7-8天啊,有几个人就可能闲了下来,做别的事情吧,product的相关bug不能关闭,没有结果。好像是出了点问题。

  当然了,也有解决的办法,就是被order在BA中需要修改的逻辑代码都注释掉,然后编译就通过了,就可以发布测试了。但是本来能用的order部分,虽然逻辑有问题,但是原来还是可以跑的,由于注释了代码,所以不能运行了。应该还有更好的解决办法。

  简单的模块划分有问题,分层开发了,后面还是有不太好的地方,而且越做越大,问题会更加明显,矛盾也会更加明显,有没有解决办法呢?

  这两种是不是可以结合起来呢?答案是:可以。

  项目整体上按照模块来划分,划分为几个小的子系统,然后再每个模块中应用分层开发的方式。刚开始我也有疑惑,比如说分为两个模块,order和product。但是订单模块里面,有时候会要求显示商品信息,订单模块就需要商品实体吧,但是这个实体在商品模块已经定义过了,是再次定义一遍呢?还是引用product模块的实体呢?定义吧,有点多余了。引用吧,耦合了。

  后来我想通了,应该是在order模块定义一个商品类。虽然表面看起来是多余了,其实订单中要看的商品和商品模块中显示的商品是不一样的,也就是显示的内容不一样。比如说在订单中可能只需要用到商品名称,编号就可以了,但是在商品模块可能需要用到更多的属性,例如:特性、标签、使用方法等。

  所以说还是应该定义两个的,如果说只是定义一个大而全的商品实体,就会发生在某些时候,可能用一两个字段,有时候用4、5个,调用的人不知道里面有没有值,可能会处理报错。最好是用几个属性,就有几个属性,这几个属性都有值。既减少错误,也减少耦合。

  下面借用一下Artech 的WCF.PetShop项目的结构图,如有不妥,请来电说明,我会及时替换。感谢Artech 给大家带来的精彩分析,以及他无私的奉献。

  

系统内部模块(子系统)之间的耦合以及模块(子系统)划分

 

  采用了上面的结构之后,如果是前面的情况,product的bug修改完毕之后,发布product相关的dll就可以了,可以进行测试,不影响order部分的使用。也算是项目的OCP(Open-Closed Protocal)原则吧。(请各位原谅我的冒用)
 
  结论
 

 

1、实体的专用性

1)        尽量的保持实体的专用性,也就是一个功能的方法,虽然和两外一个方法的返回结果类似,可能只需要添加一两个属性,这样的情况,重新建立实体,方便后面可能对这两个方法返回内容的修改不至于相互影响。

2)        尽量保持一个实体中的每一个属性,每一个被赋值的属性,将来都会用到,否则减少实体的属性,或者新建一个实体,使用正好合适的属性个数。

 

3)        分离添加和显示用的实体,因为添加可能不是每个字段都需要赋值,或者一些值是默认值。

 

4)        分离不同类型的用户使用的实体,尽管是相同的功能。可以在类名添加ForPlanter之类的后缀来解决。因为不同用户关注的点不同,关注的属性肯定不相同。而且修改也不影响其他类型用户的使用。

 

2、方法的专用性

 

保持方法的专用性,分离不同用户的业务方法和数据访问方法。也是为了后面的修改,不至于影响其他用户功能的使用。

 

3、系统划分

先按照功能模块或者是服务的对象主体来划分系统,划分为子系统。然后再每个子系统中分层,子系统之间的交互使用接口。子系统相关的后台代码独立,方便日后维护升级。

 

 

  具体分析可以参看园子中的Artech 写的一个小系列:

  WCF版的PetShop之一:PetShop简介

  WCF版的PetShop之二:模块中的层次划分

  WCF版的PetShop之三:实现分布式的Membership和上下文传递

  大家有什么想法,欢迎留言或者来电交流。

你可能感兴趣的:(数据结构,编程,软件测试,Access,WCF)