1. java Web四层顺序问题，求教
javaweb的四层/五层逻辑结构。
首先要明白为什么要分层？
分层的目的是为了简化工作流程，避免重复代码和不必要的冗余，提高开发速度和效率。
由上到下分为：
1.UI层（对用户进行显示）
2.持久化层（用来持久化数据库）
3.业务层（有丰富的业务逻辑，并进行处理，就是把实际数据库的映射到内存中，就好比把仓库的粮食放到锅里去煮还是拿去分给大家，这就是两种业务逻辑）
4.表现层（在我看来就是服务层，用来管理容器级别的服务，例如事务，安全，数据访问逻辑等等）
这是这四层结构，还有三层结构表示的：
表示层
业务逻辑
持久化
这个分层主要是看遵循哪一种标准以及分层的用途了。
就好比计算机网络中的网络结构分层，有五层的通用结构，四层的TCP/IP协议，七层的OSI协议。
我觉得不必深究，当你真实的去运用这些知识后，再去质疑也不迟。
2. Java web开发，怎样分层和体系比较好
现在一般都是MVC的思想
视图层（Jsp/Html）、控制层（Controller），模型层（Service/Impl）、Dao层（处理数据库）
3. 为什么JavaWeb项目要分层
首先让我们坐着时光机回到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调用，以及调用。
：持久层，负责数据库交互，被service调用。
这2个维度别弄混了哟。我今天主要说的是第二个维度的层哟。
我认为，第二个维度是第一个维度的延伸，其实第二个维度再加上一个表现层就完美了，这就为什么有人说是4层架构。
---------------
前戏结束，步入正题：
有些学生朋友可能会问为什么要分层呢？我本来可以在一个地方写完的东西，非要散落在各个层中，都在一起不是挺好的吗？
开发效率高呀~
跳来跳去的我脑子都晕啦。。。
这就是为什么有人会把所有的东西都扔在一个层里，比如controller层。。。
其实我们可以在jsp上把所有的逻辑以及数据库操作,数据展示全部写在一起，耦合在一起，这样开发起来貌似更快，
但是维护性非常差，有朝一日想改一个小地方，牵一发而动全一身，隐患很高，无法快速定位问题。
因此我们需要分层。
分层了之后，你理论上改了持久层的东西，逻辑层是不用变动的。
每个Dao类是跟每个表走，Dao的每个方法里就一个个的简单sql，不包含任何业务逻辑，可以被不同的service复用和调用。
经过抽象后基本上都是通用的，因而我们在定义DAO层的时候可以将相关的方法定义完毕，
这样的好处是在对Service进行扩展的时候不需要再对DAO层进行修改，提高了程序的可扩展性。
提高了程序的可扩展性。具体什么时候做这些操作，怎么做这些操作都由Service来处理。
（就像郭德纲的相声里的一句话：“行了，你甭管了”）
而Service则不是，一个Service里可以会调用多个不同的，完成特定的业务逻辑，事务控制，
封装Service层的业务逻辑有利于通用的业务逻辑的独立性和重复利用性
同时，一个Service的方法也有可能被多个Controller的方法来调用。
逻辑出问题就在Service找问题，数据库，sql有问题就在Dao层找问题，
参数解析错误，跳转错误，就在Controller上找问题。
这样快速定位问题，互不干扰。
---------------
分层架构（这里会延伸到更广阔的架构）：
回头项目玩大了，怎么办？拆！！！
具体可以搜一下：maven分模块开发，怎么玩代码依赖，怎么玩微服务，怎么玩SOA，怎么玩RPC，怎么玩bbo。
web项目发展有几个阶段啊
第一个阶段（单一应用架构）：
所有代码都耦合在一个项目里，放在一台服务器上，这种all in one的方式是有好处的。
创业初期，不用什么架构，走敏捷开发，最快速的实现需求才是王道。
你甭管我有多烂，我至少能跑起来，我至少能在外网上让你访问，让你使用。
当然了，初期的访问量很少，节省部署和运维成本才是王道呀。
听阿里的讲座，说淘宝的前期的版本用的就是一台PC机作为服务器，所有的功能耦合在一个项目里，
每次往生产环境上发版本，要上传一个600mb的包，呵呵。
第二个阶段（垂直应用架构）：
哎哟，不错哦。自己的儿子被越来越多的人访问，访问量激增，一台服务器扛不住了，
没事，我们可以玩负载均衡，玩集群。
但是！这种性能加速度其实会变得越来越小，因为你的项目是耦合在一起的。
这时，我们需要拆分项目，这里又有2个维度，按层拆，按模块拆。
将拆好的不同项目分别部署在不同的服务器上，并且再分不同的小集群。
第三个阶段（分布式服务架构）：
唉呀妈呀，访问量陡增，到这步你创业应该算成功了，开始烧投资人的钱了吧。
经过上面拆成了越来越多的模块，模块与模块交互越来越多，怎么办？
这个时候我们需要把核心的业务抽出来，作为独立的服务，慢慢发展成稳定的服务中心，
用来提升业务复用和整合。
就像阿里的大牛说过，没有淘宝的积累，天猫能那么快的出来吗？
这个时候，你的缓存，数据库，消息队列等服务都应该是分布式的。
第四个阶段（流动计算架构）
哎呀妈呀，访问量又上了一个台阶，翻了好几百倍吖，肿么办？
这个时候服务越来越多，一些容量和资源的浪费问题凸显出来，
这时我们需要一个调度中心来基于访问压力动态的管理集群容量，
提高利用率。
第五个阶段（云计算架构）
抱歉，作者正在学习中，未完待续。
4. java web 怎么用代码表示分层
表现层
jsp：页面渲染
servlet：接收用户数据（）调用业务，接收业务传来的数据，页面跳转，传递数据。
业务层
service：接受servlet传入数据，进行业务规则处理，调用，接受返回的数据，向servlet返回数据。
持久化层
：接受业务传入数据，进行对数据库进行增删改查，得到的数据向业务层返回。
5. javaweb项目结构相关，怎么能更好的分层
域模块层由实际需求中业务对象组成，比如订单明细、产品、等。
开发者在这层不用管哪些数据传输对象，而关注域对象即可。
例如，Hibernate允许你将数据库中的信息存入域对象，这样你可以在连接断开的情况下把这些数据显示到用户界面层，而那些对象也可以返回给持久层，从而在数据库里更新。
而且，你不必把对象转化成DTO（这可能导致它在不同层之间传输过程中丢失）。
这个模型使得Java开发者能很自然运用面向编程，而不需要附加编码。
6. 阐述在java中是如何分层的，可以介绍MVC架构，以一个简单的实例说明
MVC模式。
Model模式层
View视图层
Controller控制器
视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。
模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。
业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。
控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。
MVC的一个形象的例子，我要去买一辆奔驰车，那么我先要去4S店，那么这个店面就是控制层，他不会关心车子是什么制造的，只管提供车给我。那么车厂就是SERVICE层，他只管制造车子，把结果提供给4S店，那车子的零件又是怎么来的呢？他就是通过更多的零件厂商来提供，那么这些零件厂商就是DAO层。
7. java Web Project 中关于分层的问题
你这样放其实已经有分层的雏形了，但是通常业务处理和领域API会各抽象为一层，这样层次更为清晰些。业务处理通常会映射到无状态工厂里，而领域API——包括数据库IO、外部接口调用、驱动通信等——也会映射到具体的领域包。
8. 在JavaWeb体系中,如何体现三层架构思想
Dao层、Server层、Jsp分层
9. java web ，分层架构的系统，try catch 语句写在哪一层比较好呢
这个是不定，看你喜欢，或是公司规范了。还有看你的业务逻辑层在哪里。跟你的业务逻辑层走。