在網上看了許多資料,JavaEE三層架構MVC，把視圖控制器模型分開來。
那么在這里業務邏輯就應該是M。
但是什么樣的算是業務邏輯如：上傳一個文件，上傳代碼算是一個業務邏輯嗎？
數據庫操作增加時需要判斷，和一些其它這算業務邏輯嗎？（我覺得算）
但是hibernate又提供了一個離線查詢對象（DetachedCriter），提供這個接口的意思我想是在外面處理業務邏輯。
但是三層架構不是獨立的嗎？互相不干涉嗎？在service層出現sql，hql，criter不是又把dao與service連在一起了嗎？
DTO（VO），POJO，BO這些是什么，POJO對應數據庫，BO對應業務邏輯，DTO對應頁面的傳輸與顯示。
============================================================================================================
詳細理解業務邏輯：http://www.uml.org.cn/zjjs/201008021.asp
============================================================================================================
業務邏輯就是處理數據的邏輯啦。一般后台代碼也分三層 action(controller) service DAO （這里的三層不是MVC）
比如 我得到用戶名 但是在存入數據庫的時候 用戶名字段應該是前台的用戶名加上當前日期拼成的字符串
action或者controller層是第一層 一般是用來及接受數據並且做數據的非空啊 格式是否正確的驗證
如用戶名是否為空 是不是安全字符串之類的
service層一般是用來做一個業務邏輯的實現
這時候 userName = userName + new Date();
DAO層 就是與數據庫交互層啦
也就是讀寫數據庫 將邏輯層得到的新的userName插入到數據庫
============================================================================================================
其實分層是很好的。
但就是 在MVC 很多的人在action中寫業務代碼，更有人把數據庫的代碼也寫到了action中，這明明就不理解
分層的意思。應該做到各負其責。
以下是我在一個論壇在看到的。共大家分享。
我感覺mvc最重要的好處是在開發較大項目中，
可以讓流程中各個模塊各司其職。
至於
A、“很多人在Struts的Action控制器中寫業務代碼”，
只能歸咎於2點。
1、寫代碼的人“修煉”不夠。不能理解高內聚低耦合的OO思想主旨
2、項目負責人放任自流。導致代碼混亂。
B、“控制器變得依賴信息數據中心或數據庫”
現在的MVC應該大概都再用spring這樣的IOC容器再對控制器進行分層，諸如service層dao層之類，
說“依賴”，也是應該service和dao之間的依賴。
而且這種依賴是和需求相關的，也就是和業務邏輯相關的，
個人感覺也是一種“合理的存在”
C、“對象將間接地通過控制器的action耦合在一起”
這個“缺點”到很客觀。
不過，作為開發整個項目的人來說，
“構架師制定框架，程序員去實現業務邏輯“是“完美的結構”。
DDD對於中小項目可能更有“效率”，
但是對於大項目而言，
可能會讓構架師和程序員的工作分工不明確。
構架師過多的考慮業務細節；而程序員則會接觸更多，不屬於自己的“細節”
這樣可能會增加開發成本和帶來更多的bug
而“對象和action耦合在一起”，也基本符合具體業務流程設計的思考方式
(就像一串糖葫蘆，山楂的就串山楂，山葯蛋的就串山葯蛋)
（更不能指望需求定制和需求分析人員考慮構架/代碼方面的內容）
（沒有貶義，的確也不應該他們去考慮這方面的內容）
D、“重要的事情都集中在控制器中”
和B的觀點一樣，使用spring可以更好的“細化”責任、更好的執行“開閉原則”
好吧，既然是“only interesting”，那就讓它“interesting”吧
但不要“only”
這是我對作者4點的一點個人見解，
也許是被MVC“奴役”慣了，
導致思維模式僵化，說話也比較極端。呵呵
當然作為一種技術領域新的概念，
無論有任何發展都是好的。
但是存在就是有價值，
“已死”之類的詞還是有點“牽強”，
（也許有一點點點點“嘩眾取寵”的意思）
servlet 出現的時候，perl/php已死
jsp出現的時候，servlet已死
struts2出來的時候，struts1已死
============================================================================================================
業務邏輯包含2方面內容，驗證與計算
業務邏輯就是個抽象的概念，就是數據在不同的層次進行傳遞過程中形成的各種關系，比如你從數據庫中查出一條數據，要在頁面上顯示，並且要對這條數據提供增刪改的的操作，而且還要考慮根據不同的用戶區別顯示不同的信息，對應着不同的業務操作，最終所有的重點都要落到數據這個點上，
只有把軟件開發理解成一個數據不斷交互的過程，才能真正理解所謂的邏輯，業務邏輯只是其中的一種，邏輯本身就是以數據為載體的，希望能幫到你！
============================================================================================================
我想說業務邏輯跟什么三層、MVC啥的一點關系都沒。。。。
什么叫業務邏輯？“某優惠政策，A類顧客優惠10％，B類顧客優惠20％”，用於處理此業務規則的邏輯，就叫業務邏輯。
============================================================================================================
業務邏輯：是個抽象的概念，一兩句話說不清數。
首先要理解好MVC，view是顯示層，這個就不用多說了，
controller是控制層，只負責頁面的跳轉，不實現的復雜的邏輯。
Model是業務邏輯層，根據實際的開發需要，一般這個model層又分為DAO層，Service層，DAO是數據傳輸，主要對數據庫進行一些操作，Service即使服務層，很明顯是面向實際的功能的。
比如，一個簡單的登入，前台輸入username，password，DAO層寫一個方法isExist(String name,String pwd)，從數據庫中查詢是否存在。Service這時調用了這個方法實現判斷登入，isValid(String name,String pwd){ isExist(name,pwd)},當然這個邏輯不復雜，完全沒有必要用Service層，直接用Dao層就可以。
只是說明，這幾個層的關系，可以按四層多層理解。業務復雜時把model層又衍生了兩層，DTO，數據傳輸對象，POJO瞬時對象等，以后練習中會慢慢理解的，我也是自己一個人看書，做項目，過來的。我的水平現在還很爛，只能給你介紹這么多，祝你早日成長為一名高手
============================================================================================================
我覺得不必把這些概念想得過於復雜
javaee既然用於企業，就是要把企業的信息電子化，那么以前可能寫在本上或白板上的企業行為，一般認為是所謂的“業務”
比如員工考勤就是企業實際的業務，這個業務是有規范和流程的，就是所謂的“業務邏輯”。
程序中，我們把實際的問題抽象成java對象來承載信息，通過這些對象相互作用完成信息的處理和轉換，這些java代碼就被稱為“業務邏輯處理”代碼
業務邏輯應偏重企業真實的業務需求處理，也就是你開發的ssh與別人開放的ssh主要不同的部分
============================================================================================================
業務，就是business，就是一個單元（個人，組織等）給另一個單元提供的服務。邏輯（logic）就是指人們思考問題，從某些已知條件出發推出合理的結論的規律。所以邏輯不可能離開業務，這個邏輯也就是常說的業務邏輯（business logic），它是用來管理業務功能的一系列guildlines。你看到的
里的業務應該是如richard所說的業務實體（business entities），是一種簡化的說法；邏輯也是業務邏輯的簡化。
*業務邏輯是你在分析階段對你的軟件的應用領域進行分析總結出來的，它存在不依賴於你的軟件的存在，相反，它先於你的軟件存在並限制了你的軟件應有的行為。
凡是業務邏輯都應該放到中間層，不能讓客戶端去決定。有時為了減少網絡訪問次數，在客戶端會有一此與業務邏輯有關的檢驗，但在中間層這一檢驗同樣不能省略。比如上面說的日期的判斷，客戶端可以有也可以沒有判斷，但中間層一定要有這一判斷。
* 舉個例子講 日期字段 在數據庫邏輯或者說是數據層僅僅需要判斷他是不是日期類型的
但對於業務邏輯來講僅僅輸入一個日期是不夠的，比如銷售訂單的執行日期就不能比銷售訂單的制定日期早；所以判斷用戶輸入是否正確實際上 就是兩方面：首先看他是否符合數據規范其次是是否符合業務規范
*
邏輯就是人類思考的過程
業務邏輯就是模仿人類思考的過程
(這種方式最好理解,也最好修改)
頁面邏輯,
數據庫結構,
都是電腦想問題的方式
如果想要作邏輯層
那么就要先寫好業務邏輯
之后把頁面邏輯與數據庫語句
向這個方向湊
而不是定好數據庫之后把業務向數據結構上湊
這是個想法問題作的時間長了就知道其中的區別了
平時區別不是很大的....
*舉一個訂單的例子，可能有點文不對題，希望能從另一個側面加深大家對這個概念的理解：
業務邏輯是企業的行業特性、企業文化、能力結構和資源狀況所形成的個性特質下對核心業務處理的基本路徑和方式。那么我們的業務邏輯到底是什么呢？就是將訂單信息快速全息廣播到有關崗位，並行配置資源，動態調度崗位任務，讓訂單有序地在各個崗位間流動，最終在客戶的包裝物倉庫形成物為載體的閉環。這個邏輯是基於流水生產、離散加工、快速交貨、規格不一、需求復雜的基本事實和東經人恪守本職的基本屬性作出的。
在這個業務邏輯下，訂單應該是什么樣的呢？訂單除了基本的客戶基本信息、產品基本數據和技術要求之外，還必須有工藝路線、運輸方案、信用控制等方面的選擇與控制，以鎖定需求滿足的基本路徑，這樣訂單信息才算是豐滿的，它全息了訂單在公司內部流動的基本行為模式，充分表達了東經的個性。只有這樣的訂單才算有了基因
============================================================================================================
分層的優勢是我認為在於可維護、可擴展、還有就是思路清晰。
我頁面只干我顯示的事情，你后面給什么我就顯示什么，
你后面要什么我就顯示什么
數據層只管按照指令來執行，你要我做什么就做什么，反正你要滿足我的條件
哪業務層就是把數據和頁面鏈接起來來了，具體操作權放在里面
如果在一個項目完成，用戶需要添加功能或者某個功能需要修改。
我要少顯示一個字段，頁面調下
這個公式不對，業務層調下
這個數據來源不對，DAO調下
當然，實際比這個復雜得多
市面很多公式確實不會嚴格分層，他們看中的是功能實現。如果一個需求變更
哪改程序的人我覺得會一頭亂嘛，這樣對后期成本是很大的，什么可以說危險的
所以很多大公司一個項目都配備一個架構師呢。
============================================================================================================
我經常用於比喻MVC的例子是小時候玩的那種卡帶式游戲機，
Control是主機，一般來說我買一個主機就行了，只要他不壞，他就能一直讓我玩這一類的游戲。
View則是電視機和游戲手柄，電視機可以獨立工作，他不管輸入的是電視信號、影碟機信號還是游戲機信號，他只管顯示，而且他決定了我們看到的效果是怎么樣的，如果我想要個尺寸更大的或者彩色的顯示效果，我只需要買個相應的電視機就行了，手柄也是可以換的，要遙桿還是帶震動的。
Model則是游戲卡帶，他絕定了我玩的是什么游戲，是魂斗羅還是超級瑪莉，而且游戲機主機和電視機生產廠家永遠也不知道在上面有可能會運行什么樣的游戲。卡帶中可能會有游戲代碼和存儲單元，都根據游戲的需要而設計。
N層結構是一種軟件抽象的層次結構，是對復雜軟件的一種縱向切分，每一層次中完成同一類型的操作，以便將各種代碼以其完成的使命作為依據來分割，以將低軟件的復雜度，提高其可維護性。一般來說，層次之間是向下依賴的，下層代碼未確定其接口（契約）前，上層代碼是無法開發的，下層代碼接口（契約）的變化將使上層的代碼一起變化。三層結構是N層結構的一種，是人產在長時間使用中得出來的一種應用場合廣泛的N層結構，被當作一種典型的軟件層次結構而廣為流傳甚至寫入教科書。
============================================================================================================
首先說明，三層架構不是MVC，就我個人的了解，MVC是一種用於圖形用戶接口的經典設計方案，M是指模型，而非業務邏輯；
然后來解釋業務邏輯，，業務邏輯層就是專門處理業務邏輯的地方，與現實中客戶的具體業務有關，比如說權限驗證、日志記錄（這兩個例子應該是所有企業級應用里都有的模塊吧）。
然后再解釋一下三層架構，實話實說我不認為現在書中所講的SSH整合就是三層架構，三層架構是指要把用戶接口（表示層，這一層通常使用MVC模式進行設計），業務邏輯處理以及數據庫操作分離。這樣做的目的主要是為了提高程序的復用性、擴展性，以及集群部署。舉例來說，現在一個應用程序是為PC平台開發的，所以用戶交互采用Web頁面；但是今后打算應用在手持設備上，可能需要再開發一個客戶端應用程序。如果采用這種分層，那么我們需要做的只是再寫一個客戶端應用程序就好了，而不需重寫整個系統。業務邏輯層與數據庫層的分離類似。
針對你說的在service里面出現HQL、SQL的情況，就我對Hibernate的理解，其實使用了Hibernate就可以認為實現了邏輯上的業務層與持久層分離，應為使用了Hibernate就意味着你的應用程序不再依賴具體的數據庫，只要修改配置文件就可以適應各種數據庫管理系統，Hibernate把對數據庫的操作抽象成對POJO的操作。但這只是邏輯上的，因為你還不可以實現分離部署，如果要實現完全的分離，考慮將業務邏輯層與數據層加載在不同的JVM里面，使用RMI或者WebService進行交互。
============================================================================================================
MVC和業務邏輯是不同維度的問題，MVC是所有系統運行的機制的提煉，是一種模式，Controller接受請求，得到相應Model顯示在View層，額，你在百科找更精確的解釋，其實即使是桌面程序又何嘗不需要MVC，不需要將界面和邏輯解開來？解開可以提高可維護性。
對應Javaee，就是Struts，或者更早的Model1 Model2。
MVC可以想象為人機交互的邏輯。
而業務邏輯就是具體功能對應的業務功能，因為MVC的Controller在運行時最好只起到校驗、權限控制、返回數據、調用業務的作用。那下面具體邏輯做Socket編程，調用WebService，業務對象持久化、事務控制、計划調度、消息等等都需要在業務邏輯層。根據功能、依賴關系進行分層，從維護的角度，需要解耦。對應Javaee，就是Spring了。
這里就是真正的業務邏輯了。
POJO，Hibernate，這些為面向對象服務的。讓針對關系數據庫的面向對象編程變為現實。
ORM跟IOC、AOP、MVC糅在一起，你不糊就怪了。分開來理解，一點點進步。其實啊，過2年就無師自通了，再打開書會說什么MVC？哥不是就這么做的嘛！
編程時，你在以SSH或者其他的架構上開發為出發點，目標也是可以理解並優化架構為目標，在潛移默化中自然可以到達彼岸。
============================================================================================================
業務邏輯就是業務的規則，我覺得沒必要把它想得那么神宓一樣。