1. java web 怎麼用代碼表示分層
表現層
jsp：頁面渲染
servlet：接收用戶數據（）調用業務，接收業務傳來的數據，頁面跳轉，傳遞數據。
業務層
service：接受servlet傳入數據，進行業務規則處理，調用，接受返回的數據，向servlet返回數據。
持久化層
：接受業務傳入數據，進行對資料庫進行增刪改查，得到的數據向業務層返回。
2. 為什麼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個維度，按層拆，按模塊拆。
將拆好的不同項目分別部署在不同的伺服器上，並且再分不同的小集群。
第三個階段（分布式服務架構）：
唉呀媽呀，訪問量陡增，到這步你創業應該算成功了，開始燒投資人的錢了吧。
經過上面拆成了越來越多的模塊，模塊與模塊交互越來越多，怎麼辦？
這個時候我們需要把核心的業務抽出來，作為獨立的服務，慢慢發展成穩定的服務中心，
用來提升業務復用和整合。
就像阿里的大牛說過，沒有淘寶的積累，天貓能那麼快的出來嗎？
這個時候，你的緩存，資料庫，消息隊列等服務都應該是分布式的。
第四個階段（流動計算架構）
哎呀媽呀，訪問量又上了一個台階，翻了好幾百倍吖，腫么辦？
這個時候服務越來越多，一些容量和資源的浪費問題凸顯出來，
這時我們需要一個調度中心來基於訪問壓力動態的管理集群容量，
提高利用率。
第五個階段（雲計算架構）
抱歉，作者正在學習中，未完待續。
3. 在JavaWeb中mvc是不是在[表現層，邏輯層，持久層]裡面的表現層
四層架構：
展示層（web層）、業務邏輯層、數據訪問層、信息資源層
四層架構在是開發企業應用時使用的非常經典的劃分模式。
web層負責前端展示和用戶請求的處理。mvc是一個設計模式，主要用戶構建用戶界面，目的是把展示邏輯和邏輯分離。web層通常會使用MVC模式進行構建，經常使用的mvc框架包括spring mvc，struts等，都是在web層或者展示層使用的。
業務邏輯層一般應用中會有一層service抽象，實現核心業務邏輯，事務控制也在這一層實現。
數據訪問層也即層，重點負責資料庫訪問，完成持久化功能。
信息資源層主要服務資源的存儲。
所以mvc和四層（三層）結構有關系，四層架構是應用的體系（分層）結構，描述了整個應用的一個完整的劃分，而mvc是一個設計模式，通常會用於四層架構的展示層的構建上。希望我能講清楚。
4. Java web開發，怎樣分層和體系比較好
現在一般都是MVC的思想
視圖層（Jsp/Html）、控制層（Controller），模型層（Service/Impl）、Dao層（處理資料庫）
5. java web 為什麼要分層
分層是為了更好管理，理解，和可重用性
6. java Web Project 中關於分層的問題
照你這樣放也可以了，一般還要加一個service層（service.impl），如果你已經學習了struts就可以不用servlet了。其實我原來學習java web時也是使用servlet做ajax的。。
7. javaweb項目結構相關，怎麼能更好的分層
域模塊層由實際需求中業務對象組成，比如訂單明細、產品、等。
開發者在這層不用管哪些數據傳輸對象，而關注域對象即可。
例如，Hibernate允許你將資料庫中的信息存入域對象，這樣你可以在連接斷開的情況下把這些數據顯示到用戶界面層，而那些對象也可以返回給持久層，從而在資料庫里更新。
而且，你不必把對象轉化成DTO（這可能導致它在不同層之間傳輸過程中丟失）。
這個模型使得Java開發者能很自然運用面向編程，而不需要附加編碼。
8. java web ，分層架構的系統，try catch 語句寫在哪一層比較好呢
寫在業務層啦，就是DAO實現類了。
9. javaweb項目包的分層都有什麼名字組成
知道原英文的意思，就容易了。。。。。。。慢慢學啊。
如
DAO —— Data Access Object數據訪問對象（介面）
DAOImpl 上面的實現類
entity —— 數據的對象
Service（不是Server）——就是中間層、邏輯層（介面）
ServiceImpl就是上面的實現類
util就是工具類的包
Servlet——JAVA WEB小應用。因為標準的J2EE太復雜，所以沒有各種框架前，使用的很多，現在很少使用了，知道原理就行。