業務邏輯層(BLL)：主要是針對具體的問題的操作，也可以理解成對數據層的操作，對數據業務邏輯處理。如果說數據層是積木，那邏輯層就是對這些積木的搭建。 ?數據訪問層(DAL)：主要是對原始數據(數據庫或者文本文件等存放數據的形式)的操作層，而不是指原始數據，也就是說，是對數據的操作，而不是數據庫，具體為業務邏輯層或表示層提供數據服務。 ? (IDAL)它體現了“抽象”的精神，或者說是“面向接口編程”的最佳體現。抽象的接口模塊IDAL (Model)實體和數據庫表映射類(Web)web網站項目。 并不是每個系統都要分層，一般只針對一些大型系統才采用分層，你看PetShop4，總共有22個項目。大體思想是3層，從Model,DAL,BLL，然后他在各層上又采用了工廠模式，把邏輯與實現想分離，比如以前BLL直接調用DAL就好了，但現在BLL卻調用了IDAL,IDAL只是一個接口層，里面封狀了要完成的一些業務邏輯，而具體的實現則交給DAL去實現，然后借助于工廠模式DALFactory和映射完成IDAL層中類的實例化。這樣不管我們用的底層用的是什么數據庫都可以完成BLL對DAL的調用。首先你不應該將那些SQL語句放在BLL層中，而應該是由DAL層來完成和數據庫的交互。要想研究分層模式，PetShop4的確是一個相當好的例子，值得學習。

===========================================

=========================================================================================

=========================================

=======================================

Bll層作用

bll層，又叫業務邏輯層，顧名思義，就是放置業務邏輯的地方
舉個簡單的例子，飯店的優惠方案，滿100元就打9折，不滿100不打折
web頁面提供文本框等讓員工輸入金額，然后調用bll層的方法；
那bll層就是檢查金額是否滿100，再把實際金額調用dal層存入數據庫；
dal就是把金額插入數據庫，不檢查

這樣，如果哪天優惠方案變了，只要修改bll，重新編譯bll，而別的地方不用動

之所以現在很多bll就一個簡單的引用dal，1是因為作示例，沒啥業務
2是寫的不規范?

另外要說的是：三層架構主要是用于團隊開發，便于分工，比如張三做業務邏輯，他就不用去關心數據庫類型結構等信息；李四做dal，他就不用關心業務邏輯；只要定義好bll和dal的接口就可以了
如果只是個人開發，或者比較簡單的業務，用三層是浪費時間
現在網上很多代碼都是為了分層而分層，是否要分層，要根據項目的具體情況而定，不能一一概而論。

---------------------------------------------------------------------------------------------------------------------------

比如一個網站做了一個 注冊或是 登陸!
在 DAL 層呢 不去做 任何的 判斷(登陸的用戶名存在幾個 ? 注冊的信息 會不會對數據庫 有安全方面的影響啊!!等等...? 我們就可以吧這些 判斷的 屬于 業務邏輯性的東西 放在 BLL) 這樣DAL 只管 和數據庫的交互! 運行速度 會快點吧?
啊?是不是?沒錯吧?哈?
雖然 你看的項目 BLL 層沒寫什么東西!但是那一樣是一個好的習慣!? 而且易于擴展!

----------------------------------------------------------------------------------------------------------------------------

其實我們剛看三層的時候,BLL都是用來傳遞數據的,從表現層傳過來參數,然后什么都沒做,直接扔DAL去查詢數據庫,所以,我們都覺得BLL層不好用,我一開始也是這么覺得
但是吧,既然要求是這樣,那就肯定有他的作用,其實,在小項目中,BLL確實沒有用,不過,你要做個比較大的項目,不是單純的查數據庫,然后直接把數據庫查出來的表直接顯示在表現層上,而是你需要把查詢出來的數據經過一下處理,比如百度貼吧的時間顯示,當是當天的話,顯示幾點幾分,當時好幾天以前的,顯示日期,而在數據庫里,存的都是完整的日期,這樣,這個時間的處理代碼,你就可以方在BLL中處理,處理完了再返回給表現層

?

?

?

?

C/S結構開發框架中BLL層的作用

所謂的三層開發就是將系統的整個業務應用劃分為表示層，業務邏輯層和數據訪問層，這樣有利于系統的開發、維護、部署和擴展。

分層是為了實現“高內聚，低耦合”。采用“分而治之”的思想，把問題劃分開來各個解決，易于控制，延展和分配資源。

如下圖所示





業務邏輯層用于做一些有效性驗證的工作，以更好的保證程序運行的健壯性。如完成數據添加、修改和查詢業務等；不允許指定的文本框中輸入空字符串，數據格式是否正確以及數據類型驗證；用戶權限的合法性判斷等；通過以上的諸多判斷以決定是否將操作繼續向后傳遞，盡量保證程序的正常運行。

　　業務邏輯層（Business Logic Layer）無疑是系統架構中體現核心價值的部分。它的關注點主要集中在業務規則的制定、業務流程的實現等與業務需求有關的系統設計，也即是說它是與系統所應對的領域（Domain）邏輯有關，很多時候，也將業務邏輯層稱為領域層。例如Martin Fowler在《Patterns of Enterprise Application Architecture》一書中，將整個架構分為三個主要的層：表示層、領域層和數據源層。作為領域驅動設計的先驅Eric Evans，對業務邏輯層作了更細致地劃分，細分為應用層與領域層，通過分層進一步將領域邏輯與領域邏輯的解決方案分離。

　　業務邏輯層在體系架構中的位置很關鍵，它處于數據訪問層與表示層中間，起到了數據交換中承上啟下的作用。由于層是一種弱耦合結構，層與層之間的依賴是向下的，底層對于上層而言是“無知”的，改變上層的設計對于其調用的底層而言沒有任何影響。如果在分層設計時，遵循了面向接口設計的思想，那么這種向下的依賴也應該是一種弱依賴關系。因而在不改變接口定義的前提下，理想的分層式架構，應該是一個支持可抽取、可替換的“抽屜”式架構。正因為如此，業務邏輯層的設計對于一個支持可擴展的架構尤為關鍵，因為它扮演了兩個不同的角色。對于數據訪問層而言，它是調用者；對于表示層而言，它卻是被調用者。依賴與被依賴的關系都糾結在業務邏輯層上，如何實現依賴關系的解耦，則是除了實現業務邏輯之外留給設計師的任務。

---

因沒有很好的規范邏輯層所以很多人把BLL說成是DAL(Data Access Layer,數據訪問層)和UI(User Interface)層的連接橋梁或中轉站.

既然稱作業務層必然有他的用處,不僅僅是一個中轉的功能.比如要創建一個用戶,可以用以下的邏輯表示:

///?<summary>
///?用戶管理的業務邏輯層
///?</summary>
public?class?User_BLL
{
???///?<summary>
???///?增加用戶
???///?</summary>
???///?<param name="instance">用戶實例</param>
???///?<returns></returns>
???bool?AddUser(User instance)
???{
??????if?(this.Validate(instance) ==?false)?return?false;
??????return?_DAL.AddUser(instance);
???}
???
???///?<summary>
???///?用戶資料合法性檢查
???///?</summary>
???///?<param name="instance">用戶實例</param>
???///?<returns></returns>
???private?bool?Validate(User instance)
???{
??????if?(instance.UserID == "")?throw?new?Exception("用戶編號不能為空!");
??????if?(instance.UserUser == "")?throw?new?Exception("用戶名稱不能為空!");
??????if?(_DAL.Exists(instance.UserID))?throw?new?Exception("用戶名已經存在");
??????return?true;
???}
}


// 來源:www.CSFramework.com, C/S結構框架學習網

但是在大部分處理情況在開發環境中沒有嚴格要求的, 我們往往習慣把這些檢查代碼放在UI層,其實是不對的,因為沒有分離邏輯代碼使UI層臃腫而BLL層的代碼很少, 從而造就了BLL層看起來就是一個中轉站的錯覺.

轉載于:https://www.cnblogs.com/liyueting/p/6394289.html

總結

以上是生活随笔為你收集整理的DAL,IDAL,BLL,Factory作用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。