不论是采取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。在每次判断后，根据判断的结果，选择性地为实体赋值。
以上有5个if else 嵌套，看起来比较夸大，但业务逻辑简单，比较清晰，不会给程序的运行和理解带来负担，所以是可行的。
避免使用过量嵌套语句可以使用设计模式进行改进，可用装潢模式进行。
装潢模式：objec = judgeFunction(objec)
B =judgeFunction(A)
C =judgeFunction(B)
D =judgeFunction(C)
E =judgeFunction(D)
将装潢的终究结果E返回便可。
这类方法，目前来讲，我所能想到的办法是每装潢1次就得为实体多添加1个属性（不是为属性赋值）。固然，判断次数是有限、少许、可统计的，装潢次数也是有限的。设计时多添加几个属性也无太大问题。
系统优化：如果深加分析，可以斟酌，将易产生“不满足”的判断放在前面，如果不满足，立即返回，不用进行后面的其他判断，固然会有提升性能。
通过这类方式，将层与层之间的数据传输进行封装。这样，不同层之间的开发人员，就不需要过量地知道其他层的细致的问题，从而减轻了负担。开发变得更加傻瓜试，这样，程序的自动化更具可操作性。
只在情势上进行划分，在实质上，不但没有带来便利，反而变得繁琐。那只会被嗤之以鼻，遭受唾弃。设计模式的使用早期也是这类感觉，随着使用频繁，遇到繁琐问题进行使用，渐渐感觉到分成和设计模式的妙处。