巧妙传值,为队友减负

  不管是采用七层,或是沿用三层,层与层之间的工作划分都有很强的次序。既然划分好了层级,规定好了各层各自的任务,那就去尊重,照章实现就好了。各层不仅要履行好自身的职责,能在自身职责的基础上,再发放些福利,那不仅程序做得Beautiful,合作也会Beautiful!

  直面问题。举例说明一下:

  在“机房收费系统”的上机业务实现中,界面层(UI层)接收用户输入的上机所需的必要信息,封装成实体(Model),传给业务层(BLL层)。业务层在处理的过程中,需要做如下这些判断:

       ①A=“基本数据是否设定”

       ②B=“用户是否存在”

       ③C=“卡是否可用”

       ④D=“余额是否充足”

       ⑤E=“是否已经在线” 。

  从上面的5个判断,看出,每一个都只需返回一个Boolean,而且每一个Boolean都是独立的“True”或者“False”。在不满足时,为了能将明确的信息回馈给用户,明确问题,以方便用户的调整,最快地为用户提供实现。一次只能调用一个,做一个判断,有一个返回值。这个判断在BLL层进行过一遍,等传给UI层又得对返回值进行再次判断,才能得出结果。如果就这么来,那么UI完成的工作跟BLL所做处理相差不大,还徒增过程的一次调用和判断。这在任何“懒”的程序猿面前,都是难以忍受滴。

  上面的这5条判断,都必须去判断一遍,全部满足后,“上机”才能走通。所以关于对它们的判断谁先谁后,在全部满足(多数)的情况下是没有差别的,所以先不考虑。

  在BLL层将这些判断进行查询和处理,并集中判断。

  因为上机需要返回“上下机实体”mainEntity。需要为mainEntity添加一个属性Message。在每一次判断后,根据判断的结果,选择性地为实体赋值。

<span style="font-family:SimSun;">        Dim enMain As New mainEntity
        If A = True Then
            If B = True Then
                If C = True Then
                    If D = True Then
                        If E = True Then
                            '检查全部通过,上机成功!
                            enMain.Message = Nothing
                        Else
                            enMain.Message = "此卡已在线,不能重复上机!"
                        End If
                    Else
                        enMain.Message = "余额不足,请到管理员处充值后上机!"
                    End If
                Else
                    enMain.Message = "此卡已注销,拿上相关证件,请联系管理员开启!"
                End If
            Else
                enMain.Message = "用户不存在,请检查后,重新输入!"
            End If
        Else
            enMain.Message = "基本数据未设定,暂不能进行上机操作,请联系管理员!"
        End If</span>
  在UI 层,只需要做一个简单判断即可:
<span style="font-family:SimSun;">        Dim enMain As New mainEntity
        If IsNothing(enMain.Message) Then
            '上机成功!通知用户。并将用户登录信息显示在界面上。
            MsgBox("登录成功!", MsgBoxStyle.Information, "提示!")
            txtCardID.text = enMain.CardID
            txtUpTime.text = enMain.Uptime
            '……为实体赋值
        Else
            '登录失败!将具体信息回馈给用户。
            MsgBox(enMain.Message, MsgBoxStyle.Information, "提示!")
        End If</span>

  以上有5个if else 嵌套,看起来比较夸张,但业务逻辑简单,比较清晰,不会给程序的运行和理解带来负担,所以是可行的。

  防止使用过多嵌套语句可使用设计模式进行改良,可用装饰模式进行。

  装饰模式:objec = judgeFunction(objec)

         B =judgeFunction(A)

         C =judgeFunction(B)

         D =judgeFunction(C)

         E =judgeFunction(D)

  将装饰的最终结果E返回即可。

  这种方法,目前来说,我所能想到的办法是每装饰一次就得为实体多添加一个属性(不是为属性赋值)。当然,判断次数是有限、少量、可统计的,装饰次数也是有限的。设计时多添加几个属性也无太大问题。

  系统优化:如果深加分析,可以考虑,将易发生“不满足”的判断放在前面,如果不满足,立即返回,不用进行后面的其他判断,当然会有提升性能。

  通过这种方式,将层与层之间的数据传输进行封装。这样,不同层之间的开发人员,就不需要过多地知道其他层的细致的问题,从而减轻了负担。开发变得更加傻瓜试,这样,程序的自动化更具可操作性。

  只在形式上进行划分,在实质上,不仅没有带来便利,反而变得繁琐。那只会被嗤之以鼻,遭受唾弃。设计模式的使用初期也是这种感觉,随着使用频繁,遇到繁琐问题进行使用,慢慢感觉到分成和设计模式的妙处。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 12
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 12
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值