缺点：

　　1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。

　　2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

　　3、增加了开发成本。

　　规则：

　　1、系统各层次及层内部子层次之间都不得跨层调用。

　　2、Entityobject 在各个层之间传递数据。

　　3、需要在UI层绑定到列表的数据采用基于关系的DataSet传递，除此之外，应该使用Entityobject传递数据。

　　4、对于每一个数据库表（Table）都有一个Entityclass与之对应，针对每一个Entity class都会有一个BEM Class与之对应。

　　5、在数量上，BEMClass比Entity class要多，这是因为有些跨数据库或跨表的操作（如复杂的联合查询）也需要由相应的BEM Class来提供支持。

　　6、对于相对简单的系统，可以考虑将Businessclass 子层和Business Flow 子层合并为一个。

　　7、UI层和BL层禁止出现任何SQL语句。

　　错误与异常：

　　异常可以分为系统异常（如网络突然断开）和业务异常（如用户的输入值超出大范围），业务异常必须被转化为业务执行的结果。

　　1、D层不得向上层隐藏任何异常（该层抛出的异常几乎都是系统异常）。

　　2、要明确区分业务执行的结果和系统异常。比如验证用户的合法性，如果对应的用户ID不存在，不应该抛出异常，而是返回（或通过out参数）一个表示验证结果的枚举值，这属于业务执行的结果。但是，如果在从数据库中提取用户信息时，数据库连接突然断开，则应该抛出系统异常。

　　3、在有些情况下，B层应根据业务的需要捕获某些系统异常，并将其转化为业务执行的结果。比如，某个业务要求试探指定的数据库是否可连接，这时B需要将数据库连接失败的系统异常转换为业务执行的结果。

　　4、UI层除了从调用BL层的API获取的返回值来查看业务的执行结果外，还需要截获所有的系统异常，并将其解释为友好的错误信息呈现给用户。

　　难以理解和应用的实体类：

　　我在学习三层过程中，遇到的大的困惑是关于实体类这部分内容的。当时，不知道该怎么样去用它，不知道该这样去设计和协调它。关于实体类的讲解，网上也没找到很好的讲解过程。这里给大家一个建议，一定要仔细找资料去学习三层的有关内容，不要上来看这个例子。当你理解差不多之后，再去看，再去研究这个例子，那样才会有效果。

　　看完这个例子之后，我大概画了一张图来理解它：

　　学习三层有一段时间了，虽然基本上理解了三层。但是，对于三层，还是要进一步深入学习的。它是整个软件工程的一部分，是需要在实践中去感悟和理解的。所以，三层的学习是融入在接下来的学习中，做工程的过程中，多思考。这样才能将它学好，学透彻。

　　欢迎大家提出自己学习三层的感受和遇到的困惑，我们一起讨论！