假设说类实现了封装，那么三层又将相关的类进行了封装，把它们封装在三个类库中。
由于类的存在，降低了类与类之间的耦合。由于三层的存在。降低了职责不同的类之间的耦合。
所以三层的目的和面向对象的思想是一致的，就是要实现高内聚。低耦合，便于代码的更改。复用，即提高代码的灵活性。可维护性，复用性。另一点非常重要，就是安全。
我想看这篇文章的人至少对三层有一点点了解。
一定知道三层包含：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。
那么，三层中为什么“等级观念”这么强？我们先看看假如他们处在一个平等的社会会如何。
首先。从表面看，负责不同功能的代码能够互相訪问，那么就相当于能够直接互相调用每一个层里的函数，表面上看是分层了，实际依旧是“一锅粥”，又回到了之前把那些用于显示的，逻辑推断的。訪问数据库的代码都放到了一起。
违背了“单一职责”，可读性差。更改维护起来不easy。不利于面向对象思想的体现。
其次，无论谁改动代码，都能看到有关訪问数据库的代码，这样訪问数据库的代码就非常easy被改动，那么安全性怎么体现？
最后，假设软件公布了，安装到了不同的客户机上，可是突然须要更换数据库，那么每台机子上的代码就都得改动，要不就仅仅能又一次公布，又一次安装了。
所以，尽管我们的人类社会须要平等，可是在三层中我们却要等级明显，这样会提高部署，开发，维护的效率。并节省对应的费用。
明白了这些之后，我们就要在实践中保证每一层各司其职。
UI，就是接受用户输入的数据，并显示BLL层传来的一些结果。
BLL，负责对数据的业务处理。它得处理用户的请求或返回一定结果。
DAL，负责訪问数据库的数据，可能也会在本地缓存一些数据库的数据。
说完三层后，最后谈谈实体。
假设说BLL是UI和DAL之间的信使（邮递员），那么实体就是信。用户输入的信息不会直接让BLL看到，而是写到了信中。BLL拿到的仅仅是装有信的信封。假设这封信就是写给BLL的。当然BLL能够拆开信封看里面的信。假设这封信终于是要到DAL手里的。那么邮递员BLL就不是必需看了，而是把它交给DAL。
假设DAL回信了，它也是通过邮递员把信最后交到UI手里。
我们先来看UI层的一段代码：
我们看到，这段代码并没有向我上述所说把用户输入的信息封装到“信”（实体对象user）中。而是直接作为函数參数传给BLL，我们不提倡这样的做法，假设參数增多，每一个牵连到的函数都得改动參数个数。
不利于更改。这段代码有一点优点是把BLL传回来的信息封装在了信中，由于图中代码显示，把BLL层的函数的返回值赋给了user。
再来看以下这段代码。感觉会好非常多。
这里就是把用户输入的信息都封装在了enuser这个实体中。
总结：三层之间訪问遵循一定原则，上层仅仅能调用相邻的下一层，訪问方式是通过调用下一层提供给它的接口函数，而数据则是通过实体来传递。
三层之间好像是有条明线。又有条暗线一样。函数调用是你能看得见的明线，而数据的都封装在了实体其中，可是它却在三层之间穿梭，好像是条暗线一样。