理解“業務邏輯”的含義
業務是指一個實體單元向另一個實體單元提供的服務。
邏輯是指根據已有的信息推出合理的結論的規律。
業務邏輯是指一個實體單元爲了向另一個實體單元提供服務，應該具備的規則與流程。
就像你家的規矩–“喫飯前必須洗手”“有客人來要起立”“睡覺前各自說晚安”-就是業務邏輯的生活化實例。
邏輯更多的是頁面之間的層級關係、承載信息和功能模塊之間的關係的邏輯說明；
流程更多的是從用戶視角的完整場景操作流程、交互流程、頁面路徑、更注重功能順序步驟，職能劃分和基本結構等；
簡單來說，用戶看到的叫流程，看不到的叫邏輯。通過業務邏輯來調動業務流程
在軟件系統架構中，軟件一般分爲三個層次：表示層、業務邏輯層和數據訪問層：
- 表示層：負責界面和交互；
- 業務邏輯層：負責定義業務邏輯（規則、工作流、數據完整性等），接收來自表示層的數據請求，邏輯判斷後，向數據訪問層提交請求，並傳遞數據訪問結果，業務邏輯層實際上是一箇中間件，起着承上啓下的重要作用；
- 數據訪問層：負責數據讀取。
業務邏輯的內容包括四個部分：
- 領域實體：定義了業務中的對象，對象有屬性和行爲；
- 業務規則：定義了需要完成一個動作，必須滿足的條件；
- 數據完整性：某些數據不可少；
- 工作流：定義了領域實體之間的交互關係。
以大毛網購褲子爲例
- 領域實體：大毛、資金賬戶、訂單、褲子、發貨單
- 業務規則：大毛點擊購買就會生成訂單，但必須付了錢，纔會發貨，生成發貨單。
- 數據完整性：淘寶網下訂單必須登錄賬號，沒有賬號就不能成功購買。
- 工作流：搜索褲子-找到合意褲子-下單購買-付賬-收貨。
業務邏輯：搜索“褲子”-找到合意褲子-下單-必須登錄賬號-結算-付賬-收貨。
噹噹必須登錄賬號才能下單成功，亞馬遜就不需要，今天發現淘寶也不需要登錄賬號就能購買商品了，所以每個網站的規則的不同，就形成了不同的業務邏輯，業務邏輯不僅僅包括規則，還包括實體、數據完整性、工作流。如圖：
業務邏輯圖
業務邏輯也需要畫圖，叫做業務邏輯圖，它跟業務流程圖有什麼區別呢？
業務流（工作流）是業務邏輯的一部分，它定義了對象之間的交互關係，但不涉及到規則的制定，數據的完整性方面。
其實，我們平常畫的業務流程圖多數是業務邏輯圖。
所謂的三層開發就是將系統的整個業務應用劃分爲表示層，業務邏輯層和數據訪問層，這樣有利於系統的開發、維護、部署和擴展
。
分層是爲了實現“高內聚，低耦合”。採用“分而治之”的思想，把問題劃分開來各個解決，易於控制，延展
和分配資源。
所謂的三層開發就是將系統的整個業務應用劃分爲表示層，業務邏輯層和數據訪問層，這樣有利於系統的開發、維護、部署和擴展。
分層是爲了實現“高內聚，低耦合”。採用“分而治之”的思想，把問題劃分開來各個解決，易於控制，延展和分配資源。
業務邏輯層負責系統領域業務的處理，負責邏輯性數據的生成、處理及轉換。對所輸入的邏輯性數據的正確性及有效性負責，但對輸出的邏輯性數 據及用戶性數據的正確性不負責，對數據的呈現樣式不負責。
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模式解耦。至於業務，看你怎麼定義領域模型了，一般像上傳文件這種操作並不會牽扯企業的業務，那就不應該當做一個業務，但如果這個上傳是在工作流或者一些特殊處理中，則有可能上升到業務。怎麼做，要看具體問題。
懂的越多，不會的也就越多，知識之路是不斷進取的