1.Controller层:接口层，用户访问请求时对接。

Controller层负责具体的业务模块流程的控制，在此层里面要调用Serice层的接口来控制业务流程，控制的配置也同样是在Spring的配置文件里面进行，针对具体的业务流程，会有不同的控制器，我们具体的设计过程中可以将流程进行抽象归纳，设计出可以重复利用的子单元流程模块，这样不仅使程序结构变得清晰，也大大减少了代码量。

2.dao层：DAO层主要是做数据持久层的工作，负责与数据库进行联络的一些任务都封装在此，

DAO层的设计首先是设计DAO的接口，然后在Spring的配置文件中定义此接口的实现类，然后就可在模块中调用此接口来进行数据业务的处理，而不用关心此接口的具体实现类是哪个类，显得结构非常清晰，DAO层的数据源配置，以及有关数据库连接的参数都在Spring的配置文件中进行配置。

3.domain层：通常就是用于放置这个系统中，与数据库中的表，一一对应起来的JavaBean的

domain的概念，通常会分很多层，比如经典的三层架构，控制层、业务层、数据访问层(DAO)，此外，还有一个层，就是domain层。

model层：和domain区别；可能都是javaBean，

这个区别是用途不同，domain通常就代表了与数据库表--一一对应的javaBean,

model通常代表了不与数据库一一对应的javaBean，但是封装的数据是前端的JS脚本，需要使用的数据

4.service层：Service层主要负责业务模块的逻辑应用设计。

同样是首先设计接口，再设计其实现的类，接着再Spring的配置文件中配置其实现的关联。这样我们就可以在应用中调用Service接口来进行业务处理。Service层的业务实现，具体要调用到已定义的DAO层的接口，封装Service层的业务逻辑有利于通用的业务逻辑的独立性和重复利用性，程序显得非常简洁。

5.view视图层：此层与控制层结合比较紧密，需要二者结合起来协同工发。View层主要负责前台jsp页面的表示。

问题一：Service层并没有做什么实际的工作，只是接受了Servlet，同时又调用了Dao。它本身并没有什么实际意义的代码，只是接收，调用。

很显然，这样增加了代码量。当然，我很轻易感受到了。但是它的优点是什么呢？不可能没有优点的情况下仅仅是为了增加代码量吧？

问题的思考

关于 Service 层存在的意义

1.Service被称作业务层。顾名思义，它处理逻辑上的业务，而不去考虑具体的实现。

2.对于MVC模式，MVC本身并不属于设计模式的一种，它是一种设计结构，这种结构的最终目的是为了解耦，也就是不同逻辑层的代码自身改变的时候，你别影响其他层。在写项目的时候，不同的逻辑上的代码之间的解耦是很重要的。

那很显然，为了使得我们在写代码的时候，不同的逻辑层内的代码之间的关联降低到最小，我们需要在不同的逻辑层之间加一些缓冲的层来达到一些解耦的效果。

3.比如，你在视图层，不会直接去调用Dao层。

那么对于Service，就是 Servlet 和 Dao 层之间缓冲的层。通过这一层来进行解耦，使得 Dao 层内的变化不会直接影响到 Servlet 层。

例如一个 sql 语句如果需要拼接，比如说是模糊查询， 则 sql 语句需要根据用户选择的条件来进行拼接。那么，拼接这个 sql 语句的逻辑部分，就放在 service 层进行。而 Dao 层，只负责接收拼接之后的最终的 sql 语句。

最后，service 也不是就非他不可。对于极小的项目而言，加了service层，反而增加了代码量，而且Dao层种以及预见了可能出现的情况，并进行了相应的扩展。那么，此时，既不需要了。当然，大型项目可能无法在Dao层内做到这些(我也没接触到过大型项目)，就需要service了。

最终的目的也就两个词：解耦，便于扩展