【机房重构】— 登陆折射出外观模式

最近在做机房登陆功能的时候,对于外观模式的理解更加透彻了,下面和大家分享我的理解:

先来一张关于UI、Facade、BLL中对应的类的建立图:

上图中明显可以看出UI中创建了一个登陆(FrmLogin)界面,在外观层中创建了对应的登陆外观(LoginFacade)类,因为登陆涉及两个表的逻辑判断,所以BLL层创建了用户信息(UserBLL)和用户工作记录(WorkLogBLL)类。

此时外观就将B层的两个类封装成了一个类中的两个方法,对于UI来说就看不出B层中那么复杂的逻辑判断,显得那么的清楚和简单;这就好比UI中登陆这个帅气小伙子,和B层中的美女们相亲,如果自己直接去接触有时候就显得那么的杂乱和尴尬,但是此时出现了外观这个媒人,关于B层中的一些美女的基本信息,登陆这个帅气小伙直接和媒人接触了解就可以了,这样使得媒人再给UI中其它帅气小伙介绍对象的时候直接用B层中那些美女的信息就可以了,从而使得恋爱成功几率更高,代码服用更高。

敬请期待我在机房重构中揭取的其它桂冠。

时间: 2024-10-19 15:45:01

【机房重构】— 登陆折射出外观模式的相关文章

【机房合作】重新认识外观模式

机房收费系统合作版,是我们第三次与机房收费系统相遇的时刻.在个人重构的时候,我们就开始了"七层架构"之旅,其中外观模式是单独作为一层来开发的. 那个时候,也不理解外观是起到怎样一个作用,大话上的解释表面上容易理解,看完后自己也觉得很有道理.但在系统程序中,自己是只要经过BLL逻辑层的一个方法,就需要再经过一次外观,从而"解除耦合",避免了UI层与BLL层之间直接传递数据. 那个时候,在敲代码的时候就有一种感觉:每次写完B层逻辑,又要在F层重新写一次,这就是在解耦和吗

机房重构 抽象工厂+反射+配置文件

重构机房已经开始三个多星期了,从刚开始的一头雾水,到现在的柳暗花明,由开始的无从下手,到现在感觉犹 如脱胎换骨了般.和两个星期前相比,现在明朗了多了,心情也好了不少. 先给大家看一下这次重构的整体架构图: 在前面一篇博文中对三层(UI.BLL.DAL.Entity)http://blog.csdn.net/zhangzijiejiayou/article/details/38226135做了详细的介绍. 本篇博客着重总结一下在三层的基础上我所做的改进,也就是传说中的七层. 1.Facade层(外

设计模式-外观模式的理解

外观模式:为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,使得这一子系统更加容易使用. 在机房收费系统中,外观模式用来解除U层和B层之间的耦合,按着以前的做法,在U层中的功能调用B层中的方法的时候,就需要U层完全了解B层中的方法都有哪些,自己的U层又是需要用到哪一个方法,再调用B层中的方法.这样的做法使得B层的东西完全暴露在了U层中,而且增加了U层和B层两者的耦合程度,B层做出的修改要考虑到U层的调用的问题,不利于系统的安全性.增加的外观模式,把B层中的一组方法都放到外观类Fa

java/android 设计模式学习笔记(14)---外观模式

这篇博客来介绍外观模式(Facade Pattern),外观模式也称为门面模式,它在开发过程中运用频率非常高,尤其是第三方 SDK 基本很大概率都会使用外观模式.通过一个外观类使得整个子系统只有一个统一的高层的接口,这样能够降低用户的使用成本,也对用户屏蔽了很多实现细节.当然,在我们的开发过程中,外观模式也是我们封装 API 的常用手段,例如网络模块.ImageLoader 模块等.其实我们在开发过程中可能已经使用过很多次外观模式,只是没有从理论层面去了解它. 转载请注明出处:http://bl

机房重构包图(从三层+实体到三层+实体+外观+工厂+接口+SQLHelper)

刚刚开始接触三层的时候,我只做了两个登录小窗体的例子.画了简单的包图,可以说,为后面机房重构留下了大量的工作(因为三层理解没有深度,也没有理解出自己的东西).不过,欠下的总要还的.在做机房重构的时候,问题出现了.如果只用三层+实体,我能做出来,但是,要求重构不能只用三层+实体,那么,就要好好分析一下了. 首先说说三层+实体:就是表现层(U层)直接调用业务逻辑层(B层)的逻辑,业务逻辑层在直接访问数据层(D层),在把数据返回到B层后返回到U层.首先,只用三层+实体做程序时,灵活性不够高.如果想换数

机房重构时利用状态模式实现消费时间的计算

在做机房重构时,我们会在学生上下机计算学生上机时间时,会出现消费时间随着基本数据设定表中的数据变化而变化,这里不仅仅是数据的变化,还包括不同时间段内消费时间具体确定问题.主要分为三个时间段的计算 1.准备时间:即在此时间段内,消费金额为0 2.至少上机时间:如果上机时间超过了准备时间,但是少于至少上机时间,那么此时消费时间为至少上机时间 3.按正常消费时间来算:此时,消费时间大于至少上机时间后,则按照正常时间来算 通过对业务的分析,我们发现在不同时间段,最终的消费时间的计算方式是不一样的.如果我

机房重构---我们“重构”出了什么?

机房重构立即就要结束了,在这"第三个"系统结束的时候,有必要思考一下我们重构的目的了. 或许有人说,还有什么目的呀,不就是编程语言换成了.Net,做出来,调完bug,能执行就得了呗.这么浮夸的日子里,还叫什么劲啊? 对于有这样的想法的人,我必须道一声:您(白)辛苦了 ! 不管做什么事,没有一点总结性思考是无法进步的. 我以下的一些重构论述或者说反思性总结也存在很多不足,希望大家多多指正,在此先致谢! 本文将从五个方面论述一下这次的重构系统,各自是系统架构.UML图指导.设计模式应用.数

vb.net版机房收费系统——教你七层架构(三)—外观模式

上次我们看到了D层是怎样运作的,现在,我简单演示一下我的外观和B层是如何和U层和D层打交道的. 首先我跟大家说的是我的外观是按照界面功能划分的,粒度有点小,大家在做的时候,记得外观有几个就行了,但是不能没有,U层不能直接调用B层,这样就会增加U层和B层的耦合: '************************** '文 件 名:UserInfo_BLL '命名空间:BLL '内 容: '功 能: '文件关系: '作 者:邱慕夏 '小 组:邱慕夏 '生成日期:2014-06-07 17:36:4

简单的外观模式

最近机房收费系统的重构完成了,尽管就用了两个设计模式,但是却还是感觉怪怪的,总感觉外观有问题,知道昨天实验了一个晚上,才发现自己是哪里错了,现在就把我认为正确的外观介绍给大家. 什么是外观. 简单的说就是一组借口,用来连接客户端与复杂功能实现的一组借口,防止客户端与子系统内部产生耦合,从而导致客户程序随着子系统的变化也要发生变化,我们就用了一个外观模式这个借口来实现他. 为什么要用呢? 大家在编程的时候有时候会遇到这么一个问题,比如最简单的登陆来说吧,我们会先进行卡号的查询,如果卡号通过了,在进