在Javaweb中项目一般都分成action，service，dao，model层，一个功能要通过请求action，然后调用service，service调用dao层操作model层来实现。但是直接在action调用dao层，或者更极端一点，用jsp调用dao层也是可以实现功能的。
个人理解：项目分层提高了项目的可维护性和扩展性，简单来说就是需要新功能时不需要修改过多代码，项目出问题时可以快速定位出问题的位置，比如跳转出问题，就可以去控制层看代码。再一个就是解耦，适合大项目多人开发的情况。
在百度知道看到一篇不错的回答，简略叙述了web项目的发展过程，解释了web的mvc分层和Java代码分层和项目架构的发展过程，有很大的启发作用。记录一下，原文地址：https://zhidao.baidu.com/question/2206388866156884028.
首先让我们坐着时光机回到n年前的web开发。
那个时候最早都是静态的html页面，后来有了数据库，有了所谓的动态页面， 然后程序猿在编码的时候，会把所有的代码都写在页面上，包括数据库连接，包括事务控制，接收参数，各种校验，各种逻辑，各种html/js/css代码等等
怎么样？够乱吧？像一坨那什么一样，这个页面可能有成千上万行？
那么好，问题来了，回头需要修改的时候，你怎么办？
你找个东西找半天，好不容易找到了，还不敢改，怕被其他地方用了，改出连带问题。 页面一出错，定位不准到底是哪里的问题，从头到尾的挨个排查。 等等等等。 这就是大家常说的什么叫可维护性，这也是为什么越来越多的公司的规范要求不能写复杂sql。
还记得之前在东软的时候，一哥们写了一个80多行的大sql来完成一个核心的查询。 试问这个大sql天天在数据库里run，还有性能可言？再试问谁敢改？后来项目要改需求还是出现bug了，那个sql要改动，写sql的哥们改了好久才改好，因为时间长他也忘了，再后来他离职了。。。
有人问，那简单sql实现不了我的功能呀，怎么办？ 从数据库设计层面开始下手，要允许适当的冗余，把表弄好，就迎刃而解了，这也是数据库层面的一种解耦吧。 后来。。。
进入第二阶段，大家痛定思痛，决定要把页面和逻辑拆开，页面只是负责显示，逻辑都在后台。
这就出现了短暂的，在jsp里使用标签调用bean的用法。bean里耦合了除了页面之外的所有东西。
再后来。。。
进入了第三阶段，大家又痛定思痛，决定要拆成三部分，就是大名鼎鼎的MVC。
再再后来。。。
衍生出来了类似于struts/springmvc等等的mvc框架
JavaWeb项目的层有2个维度。
第一个维度是MVC的三层：
M：model，模型层，包括了你的业务逻辑和数据库操作，封装好给视图层使用的。 V：view，视图层，仅仅做的是展示数据，不包含业务逻辑，主要是jsp/html等等 C：controller，控制层，负责接收请求，调用模型层处理业务逻辑并返回给视图层。
第二个维度是java代码里的三层：
controller：控制层，负责接收参数/解析参数/封装参数，调用serivce，将service方法的返回值进行封装（如果需要），返回数据/返回页面，路由。
service：负责业务逻辑，事务控制在这层里做，被controller调用，以及调用dao。 dao：持久层，负责数据库交互，被service调用。
这2个维度别弄混了哟。我今天主要说的是第二个维度的层哟。
我认为，第二个维度是第一个维度的延伸，其实第二个维度再加上一个表现层就完美了，这就为什么有人说是4层架构。
前戏结束，步入正题：
有些学生朋友可能会问为什么要分层呢？我本来可以在一个地方写完的东西，非要散落在各个层中，都在一起不是挺好的吗？ 开发效率高呀~ 跳来跳去的我脑子都晕啦。。。 这就是为什么有人会把所有的东西都扔在一个层里，比如controller层。。。
其实我们可以在jsp上把所有的逻辑以及数据库操作,数据展示全部写在一起，耦合在一起，这样开发起来貌似更快， 但是维护性非常差，有朝一日想改一个小地方，牵一发而动全一身，隐患很高，无法快速定位问题。
因此我们需要分层。 分层了之后，你理论上改了持久层的东西，逻辑层是不用变动的。 每个Dao类是跟每个表走，Dao的每个方法里就一个个的简单sql，不包含任何业务逻辑，可以被不同的service复用和调用。
经过抽象后基本上都是通用的，因而我们在定义DAO层的时候可以将相关的方法定义完毕，这样的好处是在对Service进行扩展的时候不需要再对DAO层进行修改，提高了程序的可扩展性。
提高了程序的可扩展性。具体什么时候做这些操作，怎么做这些操作都由Service来处理。 （就像郭德纲的相声里的一句话：“行了，你甭管了”）
而Service则不是，一个Service里可以会调用多个不同的dao，完成特定的业务逻辑，事务控制，封装Service层的业务逻辑有利于通用的业务逻辑的独立性和重复利用性 同时，一个Service的方法也有可能被多个Controller的方法来调用。
逻辑出问题就在Service找问题，数据库，sql有问题就在Dao层找问题，参数解析错误，跳转错误，就在Controller上找问题。 这样快速定位问题，互不干扰。
分层架构（这里会延伸到更广阔的架构）： 回头项目玩大了，怎么办？拆！！！
具体可以搜一下：maven分模块开发，怎么玩代码依赖，怎么玩微服务，怎么玩SOA，怎么玩RPC，怎么玩dubbo。
web项目发展有几个阶段啊 第一个阶段（单一应用架构）： 所有代码都耦合在一个项目里，放在一台服务器上，这种all in one的方式是有好处的。
创业初期，不用什么架构，走敏捷开发，最快速的实现需求才是王道。
你甭管我有多烂，我至少能跑起来，我至少能在外网上让你访问，让你使用。
当然了，初期的访问量很少，节省部署和运维成本才是王道呀。
听阿里的讲座，说淘宝的前期的版本用的就是一台PC机作为服务器，所有的功能耦合在一个项目里， 每次往生产环境上发版本，要上传一个600mb的包，呵呵。
第二个阶段（垂直应用架构）： 哎哟，不错哦。自己的儿子被越来越多的人访问，访问量激增，一台服务器扛不住了， 没事，我们可以玩负载均衡，玩集群。
但是！这种性能加速度其实会变得越来越小，因为你的项目是耦合在一起的。
这时，我们需要拆分项目，这里又有2个维度，按层拆，按模块拆。
将拆好的不同项目分别部署在不同的服务器上，并且再分不同的小集群。 云计算是分布式计算的一种特殊形式，是为远程设置可扩展、可衡量的IT资源引入了使用模型
第三个阶段（分布式服务架构）：
唉呀妈呀，访问量陡增，到这步你创业应该算成功了，开始烧投资人的钱了吧。
经过上面拆成了越来越多的模块，模块与模块交互越来越多，怎么办？
这个时候我们需要把核心的业务抽出来，作为独立的服务，慢慢发展成稳定的服务中心，用来提升业务复用和整合。
就像阿里的大牛说过，没有淘宝的积累，天猫能那么快的出来吗？
这个时候，你的缓存，数据库，消息队列等服务都应该是分布式的。
第四个阶段（流动计算架构） 哎呀妈呀，访问量又上了一个台阶，翻了好几百倍吖，肿么办？
这个时候服务越来越多，一些容量和资源的浪费问题凸显出来，这时我们需要一个调度中心来基于访问压力动态的管理集群容量， 提高利用率。
第五个阶段（云计算架构） 云计算是分布式计算的一种特殊形式，是为远程设置可扩展、可衡量的IT资源引入了使用模型，提高了可用性和可靠性，减少投入。