三层大家都知道了，各种生活化的样例也就不再向大家举了。这里说说我对三层的理解。
三层：
所谓三层体系结构，是在client与数据库之间增加了一个“中间层”，也叫组件层。这里所说的三层体系。不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不唯独B/S应用才是三层体系结构，三层是指逻辑上的三层。即使这三个层放置到一台机器上。
三层到底有哪三层：
表现层（User Interface）、业务逻辑层（(Business Logic Layer）、数据訪问层（(Data Access Layer）
界面层：依据用户的详细需求。为每一个功能模块，部署输入控件、操作控件和输出控件，并调用业务逻辑层中类的方法实现功能。
业务逻辑层：为用户的每一个功能模块。设计1个业务逻辑类，此时，须要利用相关的数据訪问层类中，记录操作方法的特定集合，来实现每一个逻辑功能。
数据訪问层：为数据库中的每一个表设计一个数据訪问类，类中实现记录的插入、删除、单条记录的查询、记录集的查询、单条记录的有无推断等主要的数据操作方法。
在三层结构开发中，通常还会使用模型层。表示层、业务逻辑层和数据訪问层三层之间通过传递实体对象来达到数据传递的目的，简单来说就是数据传递的一种载体。
Modal项目中存放的是实体类。即将数据库表中的每一个字段抽取为类的字段（注意类型匹配），并封装成属性，设计构造函数，来将表抽取为类。这样的类就称为实体类。也就是说一个表会有一个相应的实体类。
在三层开发过程中另一些公用的文件，这些文件会单独放到一个项目中。
比方对数据操作类DBHelper(用来实现对于数据库的基本操作),是因为数据訪问层的代码反复度太高。所以将其封装到了一个类中，供数据訪问层来调用。
为什么要用三层：
从用户的角度也仅仅看到了界面和数据库，也就是说从用户的需求来说。就是这两层而已。可是这里三层架构它主要是为程序猿为了实现部署、开发、维护企业级数据库系统而服务的。假设我们在中间层实现了对表示层和数据库层的全然脱离，其部署、开发、维护系统的费用和时间至少减少到原来的一半。甚至很多其它。
这样说吧：将应用程序的功能分层后，数据訪问层基本能够不变，一旦用户的需求改变，首先改动业务逻辑层，界面层稍做改动就可以。这样的做法使程序的可复用性、可改动性，都得到了非常好的改善，大大提高了软件project的效率。
当然还有别的长处。比方因为U层不用直接訪问数据库大大提高了数据库的安全性。……...
总仅仅就是高内聚，低耦合。
当然三层的使用也会带来一些缺点，比方：因为不可以直接訪问数据库而减少了系统的性能。还有什么级联改动，….等等。
所以使用三层也是要有条件的。并不是全部的系统都用三层比方那些业务逻辑简单，没有真正的数据存储层就不要用三层。
总之：当业务复杂到一定层度，数据存储到一定的介质时才干够使用。
三层结构是基于模块化程序设计的思想，为实现分解应用程序的需求。而逐渐形成的一种标准模式的模块划分方法。当然我们还能够依据需求划分很多其它的层次。
无论是三层架构还是曾经学过的设计模式，它们都是软件project面向对象思想的全然体现