[置顶] 重构机房收费系统—浅谈三层

  重构机房基本完成了,期间三层重构完了,推翻之后,再重构七层(外观和工厂),再重构,来来回回用了一个月........

  重构机房从画图画到一半就废弃了,因为对三层不熟,之后,做完了,才敢重新拾起来画。画图先从包图开始,宏观上有个了解:

(一)重构机房包图:


[置顶] 重构机房收费系统—浅谈三层_第1张图片

  先前画包图的时候,跟师傅交流,结果被一个师姐给笑话了,因为我认为:它们各个层之间都是双向箭头的,后来才知道,箭头表示调用关系,B层只能被U层或外观调用,B层不能调用U层,所以不存在双向箭头,大家注意。

  在我这次重构中是严格按照上面的图中来的。

  对于UI调用外观(Facade)或者UI层调用BLL层,都可以:

  UI调用外观:客户端不知道B层的存在,降低了与B层的耦合。一旦用户的需求有变动,只改U层,加一个B层就可以了。

  UI调用B层:有些功能很单一的,其实可以直接UI层调用B层就行了,加上外观反而觉得有多此一举了。

  大家重构度数自己把握就可以了。

 

(二)重构机房用例图

  关于用例图,我觉得有两种分类的方法:

  第一种:可以按照功能来区分,功能按照大的可以分为三类:查询功能、维护功能、运算功能

  第二种:可以按照角色来区分,角色可以分为三类:一般用户、操作员、管理员

  按照功能来划分举个简单的例子:运算功能:

[置顶] 重构机房收费系统—浅谈三层_第2张图片

  按照角色划分:

[置顶] 重构机房收费系统—浅谈三层_第3张图片

  在做第一次机房的时候,我们基本上就是按照角色来划分的。

  按照角色划分:简单直观,一个用例就是一个界面,并且从整体上我们整个设计很清晰,宏观上也很容易接受。

  按照功能划分:B层是按照功能划分的,这里如果你是按照功能划分的话,B层是很简单就可以做成的,但是一定要注意不要越缠越乱就行。

  我是按照角色划分的。

 

(三)重构机房的类图

  以充值为例:

[置顶] 重构机房收费系统—浅谈三层_第4张图片

  这里两个ICard和IRecharge其实是接口,为了与上面的七层的图回应,就这样画了。

  在类图中我们不难看出U层是按照界面划分的,一个UI为一个界面,外观层和B层是按照功能划分的,一个界面可能有很多个功能,有对应一个外观和多个B层,B层的功能要细化,外观只有一个,一个外观调用多个B层。U层只知道外观不知道B层的细化功能。比如说充值(首先要判断卡号是否存在,判断充值金额是否低于最小金额,recharge表中添加数据,对应card表中cash字段的修改。),充值只有一个界面反应用户的需求,外观为一个,但是B层会有几个类分别为:查询card表、查询basicdata表、添加recharge表、修改card表。每一个功能都是一个B的类,这样降低耦合。

  关于外观层,有几种说法:

  1、可以按照用例分,一个用例分为一个外观,有不同的返回值可以通过不同的function来实现,不一定一个外观就只有一个function。

  2、可以按照用户的级别来划分,分别为:一般用户、操作员、管理员,是谁的功能就调谁的外观。

  不管是哪一种,我觉得都可以。

 

  这里我想给大家提供几条线供大家思考:

  1、外观用用户级别划分,几个功能就有几个function,用一个function来调用B层的一个类(按照功能划分)。

  2、外观用用户级别划分,几个功能就有几个function,B层用表来划分,跟IDAL层分类相同,外观中的Function调B层的时候,可能要看清楚了。

  3、外观按照界面(用例)划分,一个外观几个function,B曾可以用表来分,也可以用功能划分。

  个人认为前两种更好一点,因为通知200个人和通知100个人没有什么区别,要是能实现通知10个人不就省了很大的力气了吗?

  

  我们划分三层实际上就是解耦和,大家能宏观上不要脱离了这条主线就可以了,怎样做,给自己一个说法,说的过去就行了。





你可能感兴趣的:(重构,VB.NET,七层)