接着上次的总结,这次说下我的图情结。
在这次机房收费系统画图中,对于实体层、数据访问层、表现层的划分,并没有太多的纠结,比较纠结的是业务逻辑层。
这次重构,我采用了经典三层架构,还加了外观模式和抽象工厂加反射,在一次次的纠结中,罪魁祸首就是外观。
首先说一下我的第一版,第一次画图没有用外观,业务逻辑层是基于表现层画的,所以有多少个窗体,在业务逻辑层就差不多有多少个类与之对应。例如登陆这条线:U层有一个frmLogIn的类,在B层有一个LogInManage的类,这个类里面有一个
LogIn(userInfo:UserInfo):UserInfo的方法,这个方法调用需要用到的D层类的方法。
后来让我的师父——松姐看了之后,跟我说了下他的看法:例如检查卡号是否存在,需要在很多类中要应用,那么就可以把它抽象出来。听了这个后,感觉挺对,然后就开始做了,不过现在看来当初自己做的有点过了——我将B层的粒度划分的太小了,几乎数据访问层的一个方法是一个类,这样在业务逻辑层几乎没有什么逻辑判断,这些逻辑判断全都堆砌到了外观层。
这样一来,感觉业务逻辑层的任务没有做完,而是交给了外观层来帮它完成任务。如果说外观层也算作是业务逻辑层的话倒没有什么可说的,但是在图结构上B层也外观层是划分开的,我感觉这两个是不能混为一谈的。
个人观点如下,欢迎各位拍砖:
引用一下勇哥的一句话:三层其实就是一个外观模式!
业务逻辑层需要处理完各种业务,而不是把自己的工作推给外观或者表现层。刚刚又看了一下书,感觉外观应用最多的应该是在维护的时候用。
当一个界面用例比较多时,那么这一个界面需要实例化N个业务逻辑层,才能将这些功能一一实现,那么不如创建一个外观,将业务逻辑层的类进行整合,那么表现层在实例化时,只需要实例一个外观类,那么这个界面的内容就能全部实现。
而并不是将业务逻辑层简单的执行以下return,然后在外观层进行判断。外观层就是外观层,它并不是业务逻辑层,所以对于判断的代码,在外观也是不应该出现的。
总的来说,我感觉业务逻辑层应该这样:
业务逻辑层应该面向用例,对于需要重复使用的代码进行抽象,那么主类和抽象出来的类应该是关联关系(个人观点)。
如果一个窗体只有一两个功能,那么外观模式可有可无。如果一个窗体有好多个功能,那么就为这个窗体加一个外观,将所有的功能进行集成。在窗体实例化的时候实例该类,以达到表现层与业务逻辑层解耦的目的。