如果说类实现了封装，那么三层又将相关的类进行了封装，把它们封装在三个类库中。因为类的存在，减少了类与类之间的耦合；因为三层的存在，减少了职责不同的类之间的耦合。
所以三层的目的和面向对象的思想是一致的，就是要实现高内聚，低耦合，便于代码的更改，复用，即提高代码的灵活性，可维护性，复用性。还有一点很重要，就是安全。
我想看这篇文章的人至少对三层有一点点了解。一定知道三层包括：UI（User Interface Layer）表示层，BLL（Business Logic Layer）业务逻辑层，DAL（Data Access Layer）数据访问层。顾名思义，UI和用户紧密联系，DAL和数据库紧密联系，而BLL联系着二者。但是UI有时也想攀攀好久不联系的远房亲戚——DB（数据库），冒昧的拜访很不礼貌，中间总得有人给牵线搭桥。红楼梦中，刘姥姥想拜见王夫人，就事先和周瑞家的打了个招呼，而王夫人也没直接和刘姥姥见面，就派王熙凤去接待她。所以这里面，刘姥姥就是UI，周瑞家的就是BLL，王熙凤就是DAL，王夫人就是DB。可能不太恰当，但是三层确实也体现着一定的等级观念，UI层只能引用（访问）BLL层，BLL层只能访问DAL层，不能越级访问，而BLL和DAL又都很势利，他们却无暇顾及比自己低的层，所以BLL不能引用UI，DAL也不能引用BLL和UI。
那么，三层中为什么“等级观念”这么强？我们先看看假如他们处在一个平等的社会会怎样。
首先，从表面看，负责不同功能的代码可以互相访问，那么就相当于可以直接互相调用每个层里的函数，表面上看是分层了，实际依然是“一锅粥”，又回到了之前把那些用于显示的，逻辑判断的，访问数据库的代码都放到了一起。违背了“单一职责”，可读性差，更改维护起来不容易，不利于面向对象思想的体现。
其次，不管谁修改代码，都能看到有关访问数据库的代码，这样访问数据库的代码就很容易被修改，那么安全性怎么体现？
最后，如果软件发布了，安装到了不同的客户机上，但是突然需要更换数据库，那么每台机子上的代码就都得修改，要不就只能重新发布，重新安装了。
所以，虽然我们的人类社会需要平等，但是在三层中我们却要等级明显，这样会提高部署，开发，维护的效率，并节省相应的费用。
明确了这些之后，我们就要在实践中保证每一层各司其职。
UI，就是接受用户输入的数据，并显示BLL层传来的一些结果。
BLL，负责对数据的业务处理，它得处理用户的请求或返回一定结果。
DAL，负责访问数据库的数据，可能也会在本地缓存一些数据库的数据。
说完三层后，最后谈谈实体。
如果说BLL是UI和DAL之间的信使（邮递员），那么实体就是信。用户输入的信息不会直接让BLL看到，而是写到了信中，BLL拿到的只是装有信的信封。如果这封信就是写给BLL的，当然BLL可以拆开信封看里面的信。如果这封信最终是要到DAL手里的，那么邮递员BLL就没必要看了，而是把它交给DAL。如果DAL回信了，它也是通过邮递员把信最后交到UI手里。
我们先来看UI层的一段代码：
我们看到，这段代码并没有向我上述所说把用户输入的信息封装到“信”（实体对象user）中，而是直接作为函数参数传给BLL，我们不提倡这种做法，如果参数增多，每个牵连到的函数都得修改参数个数。不利于更改。这段代码有一点好处是把BLL传回来的信息封装在了信中，因为图中代码显示，把BLL层的函数的返回值赋给了user。
再来看下面这段代码，感觉会好很多。
这里就是把用户输入的信息都封装在了enuser这个实体中。
总结：三层之间访问遵循一定原则，上层只能调用相邻的下一层，访问方式是通过调用下一层提供给它的接口函数，而数据则是通过实体来传递。三层之间好像是有条明线，又有条暗线一样。函数调用是你能看得见的明线，而数据的都封装在了实体当中，但是它却在三层之间穿梭，好像是条暗线一样。
Binary Tree Inorder Traversal,布布扣,bubuko.com
原文地址：http://blog.csdn.net/u010378705/article/details/28609865
