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個維度，按層拆，按模塊拆。
將拆好的不同項目分別部署在不同的伺服器上，並且再分不同的小集群。
第三個階段（分布式服務架構）：
唉呀媽呀，訪問量陡增，到這步你創業應該算成功了，開始燒投資人的錢了吧。
經過上面拆成了越來越多的模塊，模塊與模塊交互越來越多，怎麼辦？
這個時候我們需要把核心的業務抽出來，作為獨立的服務，慢慢發展成穩定的服務中心，
用來提升業務復用和整合。
就像阿里的大牛說過，沒有淘寶的積累，天貓能那麼快的出來嗎？
這個時候，你的緩存，資料庫，消息隊列等服務都應該是分布式的。
第四個階段（流動計算架構）
哎呀媽呀，訪問量又上了一個台階，翻了好幾百倍吖，腫么辦？
這個時候服務越來越多，一些容量和資源的浪費問題凸顯出來，
這時我們需要一個調度中心來基於訪問壓力動態的管理集群容量，
提高利用率。
第五個階段（雲計算架構）
抱歉，作者正在學習中，未完待續。