程序员人生 网站导航

巧妙传值,为队友减负

栏目:服务器时间:2015-01-10 08:37:26

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

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

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

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

       ②B=“用户是不是存在”

       ③C=“卡是不是可用”

       ④D=“余额是不是充足”

       ⑤E=“是不是已在线” 。

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

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

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

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

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
在UI层,只需要做1个简单判断便可:
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

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

       避免使用过量嵌套语句可以使用设计模式进行改进,可用装潢模式进行。

       装潢模式:objec = judgeFunction(objec)

             B =judgeFunction(A)

             C =judgeFunction(B)

             D =judgeFunction(C)

             E =judgeFunction(D)

       将装潢的终究结果E返回便可。

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

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

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

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

------分隔线----------------------------
------分隔线----------------------------

最新技术推荐