業務邏輯是什麼?
什麼是業務邏輯?
業務邏輯就是處理數據的邏輯啦。一般後臺代碼也分三層 action(controller) service DAO （這裡的三層不是MVC）
比如 我得到用戶名 但是在存入數據庫的時候 用戶名字段應該是前臺的用戶名加上當前日期拼成的字符串
action或者controller層是第一層 一般是用來及接受數據並且做數據的非空啊 格式是否正確的驗證
如用戶名是否為空 是不是安全字符串之類的
service層一般是用來做一個業務邏輯的實現
這時候 userName = userName + new Date();
DAO層 就是與數據庫交互層啦
也就是讀寫數據庫 將邏輯層得到的新的userName插入到數據庫
什麼叫業務邏輯
不同的項目有不同的功能，不同的功能需要不同的實現，實現這些核心功能的代碼就叫業務邏輯
比如讓你實現一個功能，給你兩個數，讓你獲取它的和，你所寫的如何才能雞得任意給定的兩個數的和，這個程序實現過程即可成為業務邏輯處理。
經常有人提到業務邏輯，到底什麼是業務邏輯
你爸爸
真管的嚴
說實話吧
要是說假話容易上癮的
程序的業務邏輯
業務邏輯從名稱上來看，首先是業務，這個業務一般是指軟件要實現的功能，即客戶的業務，要實現這些業務就有一個流程，流程是按某種關係形成的一個鏈，鏈之間的關係具有一定的邏輯性，綜合起來就構成了業務邏輯。在需求分析中，一般可以用要做什麼，怎麼做來理解！
業務邏輯層的作用
業務邏輯層（Business Logic Layer）無疑是系統架構中體現核心價值的部分。它的關注點主要集中在業務規則的制定、業務流程的實現等與業務需求有關的系統設計，也即是說它是與系統所應對的領域（Domain）邏輯有關，很多時候，也將業務邏輯層稱為領域層。例如Martin Fowler在《Patterns of Enterprise Application Architecture》一書中，將整個架構分為三個主要的層：表示層、領域層和數據源層。作為領域驅動設計的先驅Eric Evans，對業務邏輯層作了更細緻地劃分，細分為應用層與領域層，通過分層進一步將領域邏輯與領域邏輯的解決方案分離。業務邏輯層在體系架構中的位置很關鍵，它處於數據訪問層與表示層中間，起到了數據交換中承上啟下的作用。由於層是一種弱耦合結構，層與層之間的依賴是向下的，底層對於上層而言是“無知”的，改變上層的設計對於其調用的底層而言沒有任何影響。如果在分層設計時，遵循了面向接口設計的思想，那麼這種向下的依賴也應該是一種弱依賴關係。因而在不改變接口定義的前提下，理想的分層式架構，應該是一個支持可抽取、可替換的“抽屜”式架構。正因為如此，業務邏輯層的設計對於一個支持可擴展的架構尤為關鍵，因為它扮演了兩個不同的角色。對於數據訪問層而言，它是調用者；對於表示層而言，它卻是被調用者。依賴與被依賴的關係都糾結在業務邏輯層上，如何實現依賴關係的解耦，則是除了實現業務邏輯之外留給設計師的任務。
業務邏輯層的主要功能是什麼?
業務，就是business，就是一個單元（個人，組織等）給另一個單元提供的服務。邏輯（logic）就是指人們思考問題，從某些已知條件出發推出合理的結論的規律。所以邏輯不可能離開業務，這個邏輯也就是常說的業務邏輯（business logic），它是用來管理業務功能的一系列guildlines。你看到的
裡的業務應該是如richard所說的業務實體（business entities），是一種簡化的說法；邏輯也是業務邏輯的簡化。
*業務邏輯是你在分析階段對你的軟件的應用領域進行分析總結出來的，它存在不依賴於你的軟件的存在，相反，它先於你的軟件存在並限制了你的軟件應有的行為。
凡是業務邏輯都應該放到中間層，不能讓客戶端去決定。有時為了減少網絡訪問次數，在客戶端會有一此與業務邏輯有關的檢驗，但在中間層這一檢驗同樣不能省略。比如上面說的日期的判斷，客戶端可以有也可以沒有判斷，但中間層一定要有這一判斷。
* 舉個例子講 日期字段 在數據庫邏輯或者說是數據層僅僅需要判斷他是不是日期類型的
但對於業務邏輯來講僅僅輸入一個日期是不夠的，比如銷售訂單的執行日期就不能比銷售訂單的制定日期早；所以判斷用戶輸入是否正確實際上 就是兩方面：首先看他是否符合數據規範其次是是否符合業務規範
*
邏輯就是人類思考的過程
業務邏輯就是模仿人類思考的過程
(這種方式最好理解,也最好修改)
頁面邏輯,
數據庫結構,
都是電腦想問題的方式
如果想要作邏輯層
那麼就要先寫好業務邏輯
之後把頁面邏輯與數據庫語句
向這個方向湊
而不是定好數據庫之後把業務向數據結構上湊
這是個想法駭題作的時間長了就知道其中的區別了
平時區別不是很大的....
*舉一個訂單的例子，可能有點文不對題，希望能從另一個側面加深大家對這個概念的理解：
業務邏輯是企業的行業特性、企業文化、能力結構和資源狀況所形成的個性特質下對核心業務處理的基本路徑和方式。那麼我們的業務邏輯到底是什麼呢？就是將訂單信息快速全息廣播到有關崗位，並行配置資源，動態調度崗位任務，讓訂單有序地在各個崗位間流動，最終在客戶的包裝物倉庫形成物為載體的閉環。這個邏輯是基於流水生產、離散加工、快速交貨、規格不一、需求複雜的基本事實和東經人恪守本職的基本屬性作出的。
在這個業務邏輯下，訂單應該是什麼樣的呢？訂單除了基本的客戶基本信息、產品基本數據和技術要求之外，還必須有工藝路線、運輸方案、信用控制等方面的選擇與控制，以鎖定需求滿足的基本路徑，這樣訂單信息才算是豐滿的，它全息了訂單在公司內部流動的基本行為模式，充分表達了東經的個性。只有這樣的訂單才算有了基因
業務邏輯層的介紹
所謂的三層開發就是將系統的整個業務應用劃分為表示層，業務邏輯層和數據訪問層，這樣有利於系統的開發、維護、部署和擴展。分層是為了實現“高內聚，低耦合”。採用“分而治之”的思想，把問題劃分開來各個解決，易於控制，延展和分配資源。業務邏輯層
在java開發中什麼是業務邏輯?
業務邏輯就是處理數據的邏輯啦。一般後臺代碼也分三層 action(controller) service DAO （這裡的三層不是MVC）
比如 我得到用戶名 但是在存入數據庫的時候 用戶名字段應該是前臺的用戶名加上當前日期拼成的字符串
action或者controller層是第一層 一般是用來及接受數據並且做數據的非空啊 格式是否正確的驗證
如用戶名是否為空 是不是安全字符串之類的
service層一般是用來做一個業務邏輯的實現
這時候 userName = userName + new Date();
DAO層 就是與數據庫交互層啦
也就是讀寫數據庫 將邏輯層得到的新的userName插入到數據庫
ecshop的業務邏輯是什麼樣的
$remember 值為1時，記住此次登錄信息，用cookie把用戶名和密碼保存在客戶端，下次打開網站時，先判斷session是否存在，如果不存在，查找cookie是否
存在，如果存在，用cookie登錄。
什麼是業務邏輯？？？？
和以前不同的是，這次我更多的參與了業務邏輯分析的過程。和客戶面談，瞭解他們的需求，常常是在做程序的時候才發礌又忽略了什麼問題，然後再拿起電話。這個反覆的過程讓人覺得煩瑣而又無趣。放下電話的剎那，我明白很多代碼其實是白寫了，然後就是修改。以前自己好象更看重的是所謂的技術能力，spring,struts,hibenate,webwork,報表，郵件，設計模式等等。現在覺得好象並不是這麼一回事，客戶並不會管你具體是用了hibenate或是JDBC，他們關心的是他們的業務流程能否實現。從這種意義上說，好的溝通能力和分析能力也許顯得更加珍貴。