重构机房收费系统—浅谈三层

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

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

（一）重构机房包图：

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

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

对于UI调用外观（Facade）或者UI层调用BLL层，都可以：

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

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

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

（二）重构机房用例图

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

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

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

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

按照角色划分：

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

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

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

我是按照角色划分的。

（三）重构机房的类图

以充值为例：

这里两个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个人不就省了很大的力气了吗？

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