業務邏輯詳解
不同的項目有不同的功能，不同的功能需要不同的實現，實現這些核心功能的代碼就叫業務邏輯 比如讓你實現一個功能，給你兩個數，讓你獲取它的和，你所寫的如何才能獲得任意給定的兩個數的和，這個程序實現過程即可成為業務邏輯處理。
“一個人了解的業務邏輯越多越細，他就是越好的需求分析師。”
難題：什麽是業務邏輯？
業務是指一個實體單元向另一個實體單元提供的服務。
邏輯是指根據已有的信息推出合理的結論的規律。
業務邏輯是指一個實體單元為了向另一個實體單元提供服務，應該具備的規則與流程。
就像你家的規矩–“吃飯前必須洗手”“有客人來要起立”“睡覺前各自說晚安”-就是業務邏輯的生活化實例。
在軟件系統架構中，軟件一般分為三個層次：表示層、業務邏輯層和數據訪問層：
- 表示層：負責界面和交互；
- 業務邏輯層：負責定義業務邏輯（規則、工作流、數據完整性等），接收來自表示層的數據請求，邏輯判斷後，向數據訪問層提交請求，並傳遞數據訪問結果，業務邏輯層實際上是一個中間件，起著承上啟下的重要作用；
- 數據訪問層：負責數據讀取。
業務邏輯的內容包括四個部分：
- 領域實體：定義了業務中的對象，對象有屬性和行為；
- 業務規則：定義了需要完成一個動作，必須滿足的條件；
- 數據完整性：某些數據不可少；
- 工作流：定義了領域實體之間的交互關系。
以大毛網購褲子為例
- 領域實體：大毛、資金賬戶、訂單、褲子、發貨單
- 業務規則：大毛點擊購買就會生成訂單，但必須付了錢，才會發貨，生成發貨單。
- 數據完整性：淘寶網下訂單必須登錄賬號，沒有賬號就不能成功購買。
- 工作流：搜索褲子-找到合意褲子-下單購買-付賬-收貨。
業務邏輯：搜索“褲子”-找到合意褲子-下單-必須登錄賬號-結算-付賬-收貨。
當當必須登錄賬號才能下單成功，亞馬遜就不需要，今天發現淘寶也不需要登錄賬號就能購買商品了，所以每個網站的規則的不同，就形成了不同的業務邏輯，業務邏輯不僅僅包括規則，還包括實體、數據完整性、工作流。如圖：
業務邏輯圖
業務邏輯也需要畫圖，叫做業務邏輯圖，它跟業務流程圖有什麽區別呢？
業務流（工作流）是業務邏輯的一部分，它定義了對象之間的交互關系，但不涉及到規則的制定，數據的完整性方面。
其實，我們平常畫的業務流程圖多數是業務邏輯圖。
所謂的三層開發就是將系統的整個業務應用劃分為表示層，業務邏輯層和數據訪問層，這樣有利於系統的開發、維護、部署和擴展
。
分層是為了實現“高內聚，低耦合”。采用“分而治之”的思想，把問題劃分開來各個解決，易於控制，延展
和分配資源。
所謂的三層開發就是將系統的整個業務應用劃分為表示層，業務邏輯層和數據訪問層，這樣有利於系統的開發、維護、部署和擴展。
分層是為了實現“高內聚，低耦合”。采用“分而治之”的思想，把問題劃分開來各個解決，易於控制，延展和分配資源。
業務邏輯層負責系統領域業務的處理，負責邏輯性數據的生成、處理及轉換。對所輸入的邏輯性數據的正確性及有效性負責，但對輸出的邏輯性數 據及用戶性數據的正確性不負責，對數據的呈現樣式不負責。
JavaEE三層架構MVC，把視圖控制器模型分開來
那麽在這裏業務邏輯就是M。
但是什麽樣的算是業務邏輯如：上傳一個文件，上傳代碼算是一個業務邏輯嗎？
數據庫操作增加時需要判斷，和一些其它這算業務邏輯嗎？（我覺得算）
但是hibernate又提供了一個離線查詢對象（DetachedCriter），提供這個接口的意思我想是在外面處理業務邏輯。
但是三層架構不是獨立的嗎？互相不幹涉嗎？在service層出現sql，hql，criter不是又把dao與service連在一起了嗎？
DTO（VO），POJO，BO這些是什麽，POJO對應數據庫，BO對應業務邏輯，DTO對應頁面的傳輸與顯示。
業務邏輯就是處理數據的邏輯啦。一般後臺代碼也分三層 action(controller) service DAO （這裏的三層不是MVC）
比如 我得到用戶名 但是在存入數據庫的時候 用戶名字段應該是前臺的用戶名加上當前日期拼成的字符串
action或者controller層是第一層 一般是用來及接受數據並且做數據的非空啊 格式是否正確的驗證
如用戶名是否為空 是不是安全字符串之類的
service層一般是用來做一個業務邏輯的實現
這時候 userName = userName + new Date();
DAO層 就是與數據庫交互層啦
也就是讀寫數據庫 將邏輯層得到的新的userName插入到數據庫
MVC和三層架構並沒有可比性三層架構是指將程序分為數據訪問、業務處理、界面三個層次，是軟甲整體架構MVC是僅僅是界面架構，也就是它其實只是三層架構的界面部分，M是指實體模型或者實體模型的一個代理，而非領域模型，C是指控制器，僅僅是做轉向，不應該包含任何業務邏輯，V就是視圖了。至於那些個什麽什麽O，都是實體在不同層的映射。另外值得一提的是，MVC在一些小的程序中也經常被當做軟件整體架構，那個時候M往往就是實體模型了，但是這種時候，V就對M產生了直接引用，也就是界面對實體產生依賴，這是很不好的（但小程序問題不大），此時可以嘗試使用MVP模式解耦。至於業務，看你怎麽定義領域模型了，一般像上傳文件這種操作並不會牽扯企業的業務，那就不應該當做一個業務，但如果這個上傳是在工作流或者一些特殊處理中，則有可能上升到業務。怎麽做，要看具體問題。
業務邏輯詳解