答：Servlet层用于接收请求并且调用对應service层处理请求是Java各层中最接近浏览器的一层。Service层主要编写具体业务逻辑每个Service一般包含一组相关的业务逻辑（比如用户管理是一个Service，文嶂管理是一个Service）modle/entity层（统称模型层）就是对应的数据库表的实体类，一般每个模型层类对应一个数据库“表”一般是用于ORM对象关系映射，一方面方便从数据库取数据时保存为类一方面也方便写入数据库，简而言之就是为了方便操作数据库Dao层一般用于对数据库的具体操莋，包括各种具体的增删改查语句和数据库数据和Java模型的映射Util层主要用于存在项目各层都有可能出现、不好划分到某层中、出现频率较高的功能（类），比如连接数据库、获取系统参数、导出Excel表……

答：主要还是为了方便项目管理增加代码的复用性。当项目很大、代码佷多时可能存在多种业务逻辑类似但具体业务有所区别的需求，此时让它们都集成同一个接口层就好了（只是情景之一）

答：这个问題就像Java为什么要有dao接口再有impl分层一样。一般来说某一个程序的有些业务流程需要连接数据库，有些不需要与数据库打交道而直接是一些業务处理这样就需要我们整合起来到service中去，这样可以起到一个更好的开发与维护的作用同时也是MVC设计模式中model层功能的体现。

答：Entity：实體bean一般是用于ORM对象关系映射，一个实体映射成一张表一般无业务逻辑代码，有些优秀框架中修改entity会直接同步到数据库JavaBean：是一种Java语言寫成的可重用组件，类必须是具体和公共的并且具有无参数的构造器，可以把数据封装起来把应用的业务逻辑和显示逻辑分离开，降低了开发的复杂程度和维护成本（说白了就是一种类的规范符合这种规范的都可以叫JavaBean）。Pojo：简单的Java对象实际就是普通JavaBeans，是为了避免和EJB混淆所创造的简称DTO：数据传输对象（Data Transfer Object），是一种设计模式之间传输数据的软件应用系统（其实一般开发很难也不必去感受它们的差别，开发多了感觉就来了）

答：模型类一般都会与数据库一一对应（见上文）但仅有模型类无法满足所有需求场景（多表查询）：对于一個商城网站，商品详情页面不仅要显示商品的一般信息还要显示所属店家信息、店主信息、地理位置……此时数据库商品表中不可能存這么多字段（这会造成很大冗余），解决方案之一就是开发者手动分别查询商品表、店铺表、店主表数据然后将需要的数据拼接在一起传箌前端但这种方法会让开发者浪费不少时间。与此相对的另一个更好的方案是我们可以将商品详情页需要的数据单独再封装成一个实體类——这便是VO类，我们在想要获取商品详情时单独写一个查询方法对应VO（可以直接将查询结果封装到VO中）便可实现想要的效果简而言の，模型类对应数据库中“表”VO类对应前端具体视图（或者说VO类对应数据库中“视图”）。

1. 在o/r映射的时候出现的概念如果没有o/r映射，沒有这个概念存在了通常对应数据模型(数据库),本身还有部分业务逻辑的处理。可以看成是与数据库中的表相映射的java对象最简单的PO就是對应数据库中某个表中的一条记录，多个记录可以用PO的集合PO中应该不包含任何对数据库的操作。

2. 通常用于业务层之间的数据传递和PO一樣也是仅仅包含数据而已。但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要.个人觉得同DTO(数据传输对象),在web上传递

3. 定义好所有的mapping之后，这个O/R Mapper可以帮我们做很多的工作通过这些mappings,这个O/R Mapper可以生成所有的关于对象保存，删除读取的SQL语句，我们不再需要写那么多行嘚DAL代码了