三层大家都知道了，各种生活化的例子也就不再向大家举了。这里说说我对三层的理解。

三层：

   所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。

三层究竟有哪三层：

表现层（User Interface）、业务逻辑层（(Business Logic Layer）、数据访问层（(Data Access Layer）

界面层：根据用户的具体需求，为每个功能模块，部署输入控件、操作控件和输出控件，并调用业务逻辑层中类的方法实现功能。

业务逻辑层：为用户的每个功能模块，设计1个业务逻辑类，此时，需要利用相关的数据访问层类中，记录操作方法的特定集合，来实现每个逻辑功能。

数据访问层：为数据库中的每个表设计一个数据访问类，类中实现记录的插入、删除、单条记录的查询、记录集的查询、单条记录的有无判断等基本的数据操作方法。

   在三层结构开发中，通常还会使用模型层。表示层、业务逻辑层和数据访问层三层之间通过传递实体对象来达到数据传递的目的，简单来说就是数据传递的一种载体。

Modal项目中存放的是实体类。即将数据库表中的每个字段抽取为类的字段（注意类型匹配），并封装成属性，设计构造函数，来将表抽取为类。这种类就称为实体类。也就是说一个表会有一个对应的实体类。

   在三层开发过程中还有一些公用的文件，这些文件会单独放到一个项目中。比如对数据操作类DBHelper(用来实现对于数据库的基本操作),是由于数据访问层的代码重复度太高，所以将其封装到了一个类中，供数据访问层来调用。

为什么要用三层：

   从用户的角度也只看到了界面和数据库，也就是说从用户的需求来说，就是这两层而已。但是这里三层架构它主要是为程序员为了实现部署、开发、维护企业级数据库系统而服务的。如果我们在中间层实现了对表示层和数据库层的完全脱离，其部署、开发、维护系统的费用和时间至少降低到原来的一半，甚至更多。这样说吧：将应用程序的功能分层后，数据访问层基本可以不变，一旦用户的需求改变，首先修改业务逻辑层，界面层稍做改动即可。这种做法使程序的可复用性、可修改性，都得到了很好的改善，大大提高了软件工程的效率。

   当然还有别的优点。比如由于U层不用直接访问数据库大大提高了数据库的安全性。……...

   总只就是高内聚，低耦合。

   当然三层的使用也会带来一些缺点，比如：由于不能够直接访问数据库而降低了系统的性能。还有什么级联修改，….等等。

   所以使用三层也是要有条件的，并非所有的系统都用三层比如那些业务逻辑简单，没有真正的数据存储层就不要用三层。

   总之：当业务复杂到一定层度，数据存储到一定的介质时才可以使用。

   三层结构是基于模块化程序设计的思想，为实现分解应用程序的需求，而逐渐形成的一种标准模式的模块划分方法。当然我们还可以根据需求划分更多的层次。

   不管是三层架构还是以前学过的设计模式，它们都是软件工程面向对象思想的完全体现

浅谈三层