java分層

① java中Dao模式怎麼分層

你好，你的問法本身有些不妥，就屬於應用中的一層。可能你想說的是以下的情況：
初級DAO模式：
例如：：寫一個類 操作1張表 針對這張表的所有操作都以方法的形式寫在這個類中 1個操作對應1個方法要求是外部通過調用這個類的方法達到操作某張表的目的時不需要寫任何和資料庫以及JDBC相關的代碼，這個類的命名就是XXDAO
比如表叫做 t_goods 商品表那麼操作它的DAO就叫GoodsDAO

高級DAO模式：
例如：即DAO工廠模式，多個XXDAO實現同一個介面或者繼承同一個基類，編寫一個工廠類通過工廠模式（簡單工廠模式或利用反射動態載入均可）獲得介面或基類對象，內部實際上封裝返回的是具體的XXDAO類的對象。簡單的說即是在1的基礎上將創建具體的XXDAO對象的方式由new變為工廠模式實現
例如：UserDAO = DAOFactory.create(...);
.save()
.delete....

② Java的三層架構都有些什麼

三層架構是一個分層式的軟體體系架構設計，它可適用於任何一個項目。MVC是一個設計模式，它是根據項目的具體需求來決定是否適用於該項目。

那麼架構跟設計模式有什麼區別呢?我們從接手一個項目開始，首先，我們需要進行架構設計，一般我們採用的就是分層式的架構設計，即我們的三層架構。

然後，在確定了架構以後，我們再根據項目的具體需求去考慮是否需要應用一些設計模式，比如是否應用我們的MVC模式，抽象工廠模式等等。(在這里我們看出，MVC與三層架構不是一個等級的，而與抽象工廠等設計模式才是一路的)

最後，確定了模式以後，就是我們的一些具體的實現了。(當然一個項目不僅僅考慮這些問題，我只是為了說明兩者的區別，將其他問題已省略)

其次，它倆劃分的層次不同。

三層架構將整個項目劃分為：表現層(UI)、業務邏輯層(BLL)、數據訪問層(DAL)。MVC即Model(模型)，View(視圖)，Controller(控制)。

③ 請問java的分層思想該怎麼理解各層之間的關系是怎樣忘代碼詳解！高手們！救救這只迷途羔羊吧！好人

分層就是把代碼按照邏輯，分成多個不同的層次。
分層的目的是讓結構更清晰，代碼編寫的時候也更好管理。

比如三層的MVC，分為model業務層，view展示層，control控制層。
更個部分的代碼相對獨立，層次的關系也很明了。有的會把model層再細分。。。
代碼詳解就算了吧。
你了解這個還是通過項目了解的好，這種分層思想也是從實際工作中總結出來的。不是憑空想像的、。

④ java開發時為什麼要和service都是model層嗎

層：層叫數據訪問層，全稱為data access object，屬於一種比較底層，比較基礎的操作，具體到對於某個表、某個實體的增刪改查
service層：service層叫服務層，被稱為服務，肯定是相比之下比較高層次的一層結構，相當於將幾種操作封裝起來。

service層要使用介面來定義有以下幾點好處：
1、在java中介面是多繼承的，而類是單繼承的，如果需要一個類實現多個service，用介面可以實現，用類定義service就沒那麼靈活。
2、要提供不同的資料庫的服務時，只需要面對介面用不同的類實現即可，而不用重復地定義類。
3、編程規范問題，介面化的編程為的就是將實現封裝起來，然調用者只關心介面不關心實現，也就是「高內聚，低耦合」的思想。

想要了解更多有關Java開發的相關信息，推薦咨詢千鋒教育。北京千鋒互聯科技有限公司（下面簡稱「千鋒教育」），成立於2011年1月，立足於職業教育培訓領域，公司現有教育培訓、高校服務、企業服務三大業務板塊。教育培訓業務分為大學生技能培訓和職後技能培訓；高校服務業務主要提供校企合作全解決方案與定製服務；企業服務業務主要為企業提供專業化綜合服務。

⑤ 闡述java 如何分層的

基本的分層，就是mvc，你可以查一下這方面的資料，當然，根據需要也有不同的分層思路，比如有的項目重效率，有的項目重流程，側重點不同，所以分的層次不同但基本的就是mvc了，然後在往上面延伸，出現了什麼業務層之類的……

⑥ java分層

com.action一般你的網站是action.com才這樣命名的
一般是存放和資料庫打交道的介面
Impl一般是放裡面那些介面的實現的

沒有統一的模板，不同項目，不同架構師出來的可能都不一樣。

⑦ 闡述在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層。

⑧ 為什麼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個維度，按層拆，按模塊拆。
將拆好的不同項目分別部署在不同的伺服器上，並且再分不同的小集群。

第三個階段（分布式服務架構）：
唉呀媽呀，訪問量陡增，到這步你創業應該算成功了，開始燒投資人的錢了吧。
經過上面拆成了越來越多的模塊，模塊與模塊交互越來越多，怎麼辦？
這個時候我們需要把核心的業務抽出來，作為獨立的服務，慢慢發展成穩定的服務中心，
用來提升業務復用和整合。
就像阿里的大牛說過，沒有淘寶的積累，天貓能那麼快的出來嗎？
這個時候，你的緩存，資料庫，消息隊列等服務都應該是分布式的。

第四個階段（流動計算架構）
哎呀媽呀，訪問量又上了一個台階，翻了好幾百倍吖，腫么辦？
這個時候服務越來越多，一些容量和資源的浪費問題凸顯出來，
這時我們需要一個調度中心來基於訪問壓力動態的管理集群容量，
提高利用率。

第五個階段（雲計算架構）
抱歉，作者正在學習中，未完待續。

⑨ 弄不懂java項目的分層思想

建議 樓主了解下MVC
一般的項目大概分為4層
就是數據操作層
一般放對資料庫進行操作的方法,比如查找某條數據
biz 業務處理層
對用戶的數據進行業務邏輯處理比如注冊時,判斷用戶注冊的用戶名是否已存在,如果已存在返回用戶錯誤信息,否則將用戶注冊的信息寫入資料庫
servlet 邏輯判斷層
對頁面的請求響應數據進行邏輯處理,如封裝等
jsp 表現層
將程序處理的最終結果顯示給用戶

他們之間的聯系就是,比如注冊:
用戶在jsp頁面進行表單填寫,點擊提交到一個servlet,servlet將注冊信息封裝成javaBean交給biz層處理,這時候biz層對javaBean解封將用戶注冊的用戶名提取出來調用層的checkUserName()進行判斷該用戶名是否已存在.如果存在返回一個信息給servlet告知用戶該用戶名已存在,請重新注冊.如果該用戶名不存在,說明可注冊,biz再調用層的savaUser()方法將用戶的注冊信息寫入資料庫,返回servlet一個注冊成功的信息,最後由servlet將這些處理的最終結果返回給jsp頁面給用戶.

建議樓主去多看看別人的項目,或者自己寫些小項目這樣在寫程序的過程中能更貼切的理解這些過程存在的意義
總之,分層思想的存在是更方便的管理和維護

⑩ Java的有幾種技術架構

Java架構：

軟體架構作為一個概念，體現在技術和業務兩個方面。
從技術角度來說：軟體架構隨著技術的革新不斷地更新其內容，軟體架構建立於當前技術和一些基本原則的基礎之上。
先說一些基本原則：
分層原則：分層是為了降低軟體深度復雜性而使用的關鍵思想，就像社會有了階級一樣，軟體有了層次結構。
模塊化原則：模塊化是化解軟體廣度復雜的必然手段，模塊化的目的就是讓軟體分工。
介面實現分離原則隨著軟體模塊化的不斷深入改進，面向介面編程而不是面向實現編程可以讓復雜度日趨增高的軟體降低模塊之間的耦合度，從而讓各模塊更輕松改進。從這個原則出發，軟體也從微觀進行了細致的規范化。
還有兩個比較小但很重要的原則：
細節隱藏原則很顯然把復雜問題簡化，把難看的細節隱去，能讓軟體結構更清晰。其實這個原則使用很普遍，java/c++語言中的封裝原則以及設計模式中的Facade（外觀）模式就很能體現這個原則的精神。
依賴倒置原則隨著軟體結構的進一步發展,層與層之間、模塊與模塊之間的依賴逐漸加深，而層、模塊的動態可插拔要求不端增大。依賴倒置原則可看視為介面實現分離原則的深化，根據此原則的精神，軟體進入了工具時代。這個原則有點類似於知名的好萊塢法則：Don't call us, we'll call you。

以上這些原則奠定了我們的軟體架構的價值指標。但軟體架構畢竟是建立在當前技術之上的。而每一代技術都有架構模式。過去的不再說了，讓我們現在就來看一下當前流行的技術，以及當前我們能採用的架構。

因為面向對象是當前最流行開發技術，且設計模式的大量使用使面向對象的走向成熟，而資料庫是當前最有效的存儲結構、web界面是當前最流行的用戶介面，所以當前最典型的三層次架構就架構在以上幾項技術的基礎之上，用資料庫作存儲層、用面向對象來實現業務層、用web來作為用戶介面層。我們從三層次架構談起：
因為面向對象技術和資料庫技術不適配，所以在標准三層次架構的基礎上，我們增加了數據持久層，來管理O-R雙向映射，但目前一直沒有最理想的實現技術。cmp和entity bean技術因為其實現復雜，功能前景有限，已接近被淘汰的邊緣。JDO及hibernate作為o-r映射的後期之秀，尤其是hibernate，功能相當完備。推薦作為持久層的首選
在業務層,因為當前業務日趨負載，且變動頻繁，所以我們必須有足夠敏捷的技術來保證我們的適應變化的能力，在標准j2ee系統中session bean負責業務處理，且有不錯的性能表現，但採用ejb系統對業務架構模式改變太大，且其復雜而昂貴，業務代碼移植性差。而spring 作為一個bean配置的輕量級架構，漂亮的IOC模式實現，對業務架構影響小，所以推薦作為中間層業務框架。
在用戶結構層,雖然servlet/jsp/jstl/javaBean 能夠實現MVC架構,但終究過於粗糙。struts對MVC架構的實現就比較完美，Taperstry也極好地實現MVC架構，且採用基於事件的方式，非常誘人，惜其不夠成熟，我們仍舊推薦struts作為用戶介面層基礎架構。
因為業務層是三層次架構中最有決定意義的，所以讓我們回到業務層細致地分析一下，在復雜的業務我們常常需要以下基礎服務的一種或幾種：事務一致性服務acid(tool:jta/jts)、並發加鎖服務concurrent&&lock、池化管理服務cache、訪問控制服務(tool:jaas)、流程式控制制服務workflow、動態實現服務IOC，串列化消息服務(tool:jms)、負載平衡服務blance等。如果我們不採用重量級應用伺服器(如weblogic,websphere,jboss等)及重量級組件(EJB)，我們必須自己實現其中一些服務。雖然我們大多情況下，不需要所有這些服務，但實現起來卻非易事。幸運的是我們有大量的開源實現代碼,但採用開源代碼卻常常是件不輕松的事。

隨著xml作為結構化信息傳輸和存儲地位日漸重要,一些xml文檔操作工具(DOM,Digester,SAX等)的使用愈發重要,而隨著xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，採用xml schema來設計xml文檔格式,然後採用java binding來生成java bean 會成為主要編程模式,而這又進一步使數據中心向xml轉移,使在中小數據量上,愈發傾向於以xquery為查詢語言的xml資料庫。最近還有一個趨勢,microsoft,ibm等紛紛大量開發中間軟體如(microsoft office之infopath)，可以直接從xml schema 生成 錄入頁面等非常實用的功能。還有web service 的廣泛應用，都將對軟體的架構有非常重大的影響。至於面向服務架構(SOA)前景如何，三層次架構什麼時候走入歷史，現在還很難定論。

aop的發展也會對軟體架構有很深的影響，但在面向對象架構里，無論aspectJ還是jboss-aop抑是aspectWerks、nanning都有其自身的嚴重問題:維護性很差,所以說它將很難走遠。也許作為一個很好的思想，它將在web service里大展身手。

rdf,owl作為w3c語義模型的標志性的語言,也很難想像能在當前業務架構發揮太大影響。但如果真如它所聲稱那樣，廣泛地改變著信息的結構。那麼對軟體架構也會有深遠影響。

有關架構設計的一些忠告：
盡量建立完整的持久對象層.可獲得高回報
盡量將各功能分層,分塊,每一模塊均依賴假定的其它模塊的外觀
不能依賴靜態數據來實現IOC模式，應該依賴數據特徵介面，靜態數據僅是數據特徵介面實現方式之一
架構設計時xml是支持而不是依賴.但可以提供單一的xml版本的實現

從業務角度說：軟體架構應是深刻體現業務內部規則的業務架構，但因為業務變化頻紝，所以軟體架構很難保持恆定不變，但業務的頻繁變化不應是軟體架構大規模頻繁變化的原因，軟體架構應是基於變化的架構。
一種業務有其在一段時間內穩定存在的理由(暫且不談)，業務內部有許多用例，每一種用例都有固定的規則，每一規則都有一些可供判定的項，每一項從某一維度來觀察都是可測量的，我們的架構首先必須保證完美適應每一項每一種測量方式，很多失敗的架構都是因為很多項的測量方式都發生變更這種微觀變化中。

每個用例都有規則，我們在作業務用例分析，常常假定一些規則是先驗的，持久穩定的，然而後來的業務改變常常又證明這種看法是錯誤的，然而常常我們的架構已經為之付出了不可挽回的代價。大量事實證明：規則的變化常常用例變化的根本原因。所以我們的架構要盡可能適應規則的變化，盡可能建立規則模版。

每個用例都關系著不同的角色。每一個用例的產生都必然是因為角色的變更（注意：不是替換，而是增強或減弱），所以注意角色的各種可能情況，對架構的設計有舉足輕重的意義。在我們當前的三層架構里，角色完美地對應介面概念。

在一個系統里很多用例都相互關聯,考慮到每個用例均有可能有不同的特例，所以在架構設計中，盡量採用依賴倒置原則。如架構許可可採用消息通信模式(JMS)。這樣可降低耦合度。

現在我們談一下業務穩定存在理由對業務的影響。存在即是合理，在這里當然是正確的。業務因人而存在，所以問業務存在的理由即是問不同角色的需要這項業務的理由以及喜歡不喜歡當前業務用例的理由，所有這樣的角色都應該在系統里預留。《待續》
在架構設計中有幾個原則可以考慮：
用例盡量細分
用例盡量抽象
角色盡量獨立
項測量獨立原則
追求簡單性
這里未提供相關的例子，例子會在以後的更新時提供。

業務和模式之間的關系
業務中的一些用例之間的關系常常和一些常規的模式很相似。但隨著時間的演化，慢慢地和先前的模式有了分歧。這是個正常的現象。但這對系統架構卻要求非常高，要求系統架構能適應一些模式的更替。在這里我們盡可能早地注意到用例之間的相互角色變化，為架構更新做好准備.