首先，分层的目的：高内聚，低耦合。虽然有时候一个controller方法里面仅仅调用一个service的方法，一个service方法里面仅仅调用一个dao层里的方法，但是，这几层还是非常有必要存在的。一、这样看起来结构是很清晰的，虽然对很对新人来说确实看起来很复杂；二、可扩展性和适应性更加强，比如将来用户的业务逻辑有一定的改变，你需要做的仅仅就是在service层中多调用一个方法即可，而不需要对代码有太多的改动，抑或是你将来想换个mvc的框架的话，只需要对接收和返回参数方面做些处理即可，而不需要对service层和dao层做任何改动；三、维护更加简单，其实这个和第二点有点相似，不过，不同的是将来维护的不一定是你本人或者开发这个系统的人，所以，如果你严格按照这种架构来写的话，他们只需要有这种分层意识，很容易就能够对系统有个很好的掌握，也很容易能够对问题进行排查和修改。
view：视图。这个很容易理解，其实view层就是用户用户可以看到的东西。后台怎么处理不关心，只关心怎么样想用户展示信息。
controller：也可以成为action层，业务模块流程。我经常喜欢用控制视图的跳转来简单形容，但是这个是不全面的，因为他除了控制视图的转换之外，还控制了业务的逻辑，但是，这里的控制业务逻辑不是业务逻辑的实现，而仅仅是一个大的模块，你看到之后，知道它实现了这个业务逻辑，但是怎么实现的，不需要关心，仅仅需要调用service层里的一个方法即可，这样使controller层看起来更加清晰。
service：业务逻辑层。接着controller层中，可以想到，service层是业务逻辑（商务逻辑）的具体实现。它向上层的controller层提供接口，并且使用dao层提供的接口。存在的必要性：有时候，我认为更多的时刻，service层中仅仅是调用dao层中的一个方法，那么它是否有必要存在呢？答案是肯定的。因为，假如将来客户的业务有一定的变动，那么这样一来，你只需要在service层中进行一些变动即可。记住，你写程序不应该仅仅为实现功能考虑，更多的还是应该为将来的维护考虑，因为大部分的时间还是在维护上的。
dao：数据访问对象。他只负责对数据进行访问，而不管其他的什么业务逻辑，其实就是只干活，而不管为什么干。在dao层里面要完成的是数据访问逻辑以及对数据的访问。数据访问，大部分情况下就是对数据进行操作。dao层为上层的service层提供接口。dao层在操作完成后，如果是查询，则返回对象，如果是增删改，则仅仅需要返回一个boolean值表示成功失败即可。