在学习三层的过程中，有一个问题让我很郁闷，就是为什么偏偏是三层，而不是二层或者四层，查阅了资料知道，不是二层是因为那样就会出现高度耦合的问题，而不是四层是因为实体类（Entity），它仅仅可以用作一种方法，没有它系统照样可以工作，有了它可以更加方便工作。
下面先来用一个生活中的例子来理解一下：
UI层（淘宝）：日常生活中我们会在淘宝上买东西，我们需要什么东西，就会加入购物车，这个时候就将所需的数据传给了B层，也就是形成了订单。这一层来接受B层的订单详情，也就是用户通过淘宝网知道自己买的东西到了哪里。这就是界面层。
B层（订单）：客户将数据提交后，在订单中进行处理，判断，如是否有该商品，是否有少填东西，所有都坚持无误后，将数据传给D层，即商家。D层将发货信息传递给该层。这就是业务逻辑层。
D层（商家）：商家接受到有B层传来的数据后，开始在自己的商店中找对应所需要的物品，找到后开始进行发货，同时将物流信息返回到B层，即我们熟知的订单详情。这就是数据访问层。
Entity(实体类)：它不属于任何一层，也可以叫做公共层（“大众情人”），上面的三层都需要用到这个类，它用于在各个层之间进行数据的传递。
那么为什么要用实体类呢？
实体类，即数据表的映射，数据库中DatsSet 不具备OO的优点， 实现数据检索繁琐，易出错， 使数据结构暴露在业务逻辑层和表现层，因此使用实体类在各个层之间进行传递，它符合面向对象的抽象封装思想，如果程序需要改动，只需要改动实体类，方法间调用接口，符合面向对象接口不变。
那么应用三层有什么作用呢？它的优缺点是什么？
三层的作用：符合“高内聚，低耦合”的思想，但不是处处都要想三层，有时候一个简单的系统用了三层往往会使问题复杂化。
优点：
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。
缺点： 1、降低了系统的性能。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。