再谈三层架构
再谈三层架构
白志华 发表于2年前
再谈三层架构
  • 发表于 2年前
  • 阅读 4
  • 收藏 0
  • 点赞 0
  • 评论 0

标题:腾讯云 新注册用户域名抢购1元起>>>   

    再次谈起三层架构来,初识三层时的那种向往,那种青涩,已经不见了踪影,取而代之的是对分层的感慨。

    分层,三层也好,七层也罢,都是将页面显示、业务逻辑控制、数据访问进行解耦。还有MVC和设计模式也是这样。只分UI,BLL,DAL这三层,只是实现了基本的解耦,但是耦合性还是很高的,尤其是对于中型及以上的系统来说,简单的三层并不能满足其需求。DAL提取出DBHelper,BLL中提取出Facade层,还有各层之间其实都应该加上接口。这样系统的灵活性才会大大提高。

    对于B层的划分,有人说按数据表走,一个表一个类;有人说按窗体走,一个窗体一个类(PS:我这里是重构,有原系统做参考,如果是开发一个新系统,则没有这种说法);有人说按用例走,一个用例一个类。合作开发完以后,我好好分析了一下这三者。第一种方法,B层的类会相对少一些,维护工作会比较轻松,不过假如增加一个功能,那么就得相应的修改B层的类,不满足开闭原则。第二种方法,局限性更大。只要修改窗体,就得修改类。这样给人的感觉,B层依赖于UI层。但是分层应该是上层依赖于下层。第三种方法,满足开闭原则,添加功能,直接添加一个类即可。但是不足的是B层中类太多了。分析之后。我觉得应该改善第三种方法,在B层包中,为每个表添加一个子包,然后对应B层的操作放到对应子包中。这样就不会太乱了。添加功能时,直接在对应的子包中添加类。一个用例一个类。满足了开闭原则和单一职责原则。

    对于Facade层如何划分,暂时没有确定的想法。有2种观点:一是将有关系的类,相近的类放到一个外观类。另一种观点按UI层来划分。不过感觉第一种观点稍微科学一点。暂时没有更好的想法。

    在个人版和合作版开发完后,感觉接口挺重要的,开发接口可以大大增加系统的灵活性。而且,每一层只要针对于接口进行编程即可。不用考虑下一层的具体实现。下一层如何更改都无关紧要,只要接口不变,那么系统运行无阻碍。在开发前期,先开发接口,这样上层接口在编程时,调用下层会很容易,且不易出错。调试的时候也很方便。

版权声明:本文为博主原创文章,未经博主允许不得转载。

共有 人打赏支持
粉丝 29
博文 260
码字总数 57524
×
白志华
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: