A. 开发Web程序除了MVC之外还有什么可用的分层模型
Model（模型） View（视图） Controller（控制器），业务逻辑、数据、显示分离，便于开发、维护。个人理解。
B. Web应用程序为什么分层开发
分层不是为了代码的化简，实际上分层之后代码只会增加。
分层是为了整个应用的设计和维护。
如果你要开发一个简单且永久不变的应用，当然可以将一堆代码放在一起。但现在的技术发展和用户需求的变化如此之快，谁能保证开发一个系统之后可以一直用下去。当你想修改程序的一些功能的时候，发现自己编写的东西全部集中在一个文档里，太杂了，牵一发而动全身，消耗太大了。同样，设计的时候要考虑所有的逻辑还要考虑视图在内，不乱才怪。
分层之后，上一层只需要调用下一层提供的接口就能使用下一层提供的服务，而下一层对上一层不具有依赖性，增加代码的可测试性和可重用行。
web应用分层方式很多，一般分为表现层，业务逻辑层和数据访问层，如果要改变视图就直接在表现层操作，不用修改另外的两个层。而且不同层可以教给不同人员去开发，再整合一下就可以了，是不是清晰很多了呢
C. java Web Project 中关于分层的问题
照你这样放也可以了，一般还要加一个service层（service.impl），如果你已经学习了struts就可以不用servlet了。其实我原来学习java web时也是使用servlet做ajax的。。
D. 1， 为什么需要MVC模式，以前简单的JSP页面处理不好吗MVC有什么好处呢
MVC就是常说的：模型(Model),视图(View)和控制Controller)
它把业务处理和Jsp页面分开了。而以前的Jsp页面是把所有的代码都写在Jsp页面中，那样不利于维护
MVC模式的目的就是实现Web系统的职能分工。
MVC模式的好处：
1.各施其职，互不干涉
在MVC模式中，三个层各施其职，所以如果一旦哪一层的需求发生了变化，就只需要更改相应的层中的代码而不会影响到其它层中的代码。
2.有利于开发中的分工
在MVC模式中，由于按层把系统分开，那么就能更好的实现开发中的分工。网页设计人员可以进行开发视图层中的JSP，对业务熟悉的开发人员可开发业务层，而其它开发人员可开发控制层。
3.有利于组件的重用
分层后更有利于组件的重用。如控制层可独立成一个能用的组件，视图层也可做成通用的操作界面。
E. Java web开发，怎样分层和体系比较好
现在一般都是MVC的思想
视图层（Jsp/Html）、控制层（Controller），模型层（Service/Impl）、Dao层（处理数据库）
F. 在web应用的分层结构中，事务控制应该处于哪一层
Action层做控制器；Service层做业务逻辑处理；Dao层做数据库处理。
Service层处理方法中用到多个Dao实例是常见的，所以当然要把事务控制搁在这一层。
G. 信息系统的三层结构分别是什么
三层结构是：
1、数据访问层：主要看你的数据层里面有没有包含逻辑处理，实际上他的各个函数主要完成各个对数据文件的操作。而不必管其他操作。 位于最外层（最上层），离用户最近。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。
2、业务逻辑层：主要负责对数据层的操作。也就是说把一些数据层的操作进行组合。业务逻辑层（Business Logic Layer）无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为领域层。
3、表示层：主要对用户的请求接受，以及数据的返回，为客户端提供应用程序的访问。
H. 为什么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个维度，按层拆，按模块拆。
将拆好的不同项目分别部署在不同的服务器上，并且再分不同的小集群。
第三个阶段（分布式服务架构）：
唉呀妈呀，访问量陡增，到这步你创业应该算成功了，开始烧投资人的钱了吧。
经过上面拆成了越来越多的模块，模块与模块交互越来越多，怎么办？
这个时候我们需要把核心的业务抽出来，作为独立的服务，慢慢发展成稳定的服务中心，
用来提升业务复用和整合。
就像阿里的大牛说过，没有淘宝的积累，天猫能那么快的出来吗？
这个时候，你的缓存，数据库，消息队列等服务都应该是分布式的。
第四个阶段（流动计算架构）
哎呀妈呀，访问量又上了一个台阶，翻了好几百倍吖，肿么办？
这个时候服务越来越多，一些容量和资源的浪费问题凸显出来，
这时我们需要一个调度中心来基于访问压力动态的管理集群容量，
提高利用率。
第五个阶段（云计算架构）
抱歉，作者正在学习中，未完待续。