3

我有(或將要)有一個DAL包含我們的ERP系統的數據訪問方法。一個數據訪問層爲多個業務層提供服務?或不?

商業方面有使用此DAL的上下文。例如:條形碼應用程序,自定義銷售揀配應用程序,採購訂單應用程序。

我在想,不是爲我的業務層創建一個DLL來將它分解到這些主要區域,從而使它們可靠地與DAL進行通信。這將有助於減少我的成品應用程序的膨脹

這是我的第一個問題,第二個問題是,業務層之間通用的Data Acess對象應該駐留在單獨的項目中以便所有BL都可以訪問?因爲許多方法將這些對象的列表返回給業務層或直接返回到演示文稿(不常見但會發生),因此這些數據訪問對象也可用於DAL。他們是否應該提到具有DAO的同一個班級?

回答

1

我認爲你對第二個問題的回答是相當清楚的; DAL應該有自己的項目。

至於第一個,它實際上取決於不同應用程序需求的共同性。您還需要考慮是否分解爲多個BLL DLL會增加維護業務邏輯的複雜性。

我希望在最後一項訪問DAL以及來自同一用戶界面的BLL時保持警惕。這意味着你可以對兩者都有依賴性。將簡單的方法放入BLL中可能會更好,該BLL只調用DAL功能並返回答案,以便從UI到BLL再到DAL。

當然,所有這些都需要考慮哪些答案最適合您的應用程序和開發方法。

+0

例如,如果我有一個名爲Employee的類,我希望我的BLL和DAL能夠訪問它,我應該怎麼做?我如何避免它?我不希望我的DAL方法返回數據表,我想返回員工記錄,BLL和他們做一些邏輯並與UI進行通信。 – e4rthdog

1

您可以擁有您的DAO和BL都可以使用的域對象。領域對象應該是非常愚蠢的,它應該是一個給定實體的表示。

實施例:

Bl.Get-僱員 - >返回域對象僱員

BL.Get-僱員方法調用轉換數據挖掘成域對象,在這種情況下一個僱員的DAO域對象。

Bl.Get-employee >> Calls DOA.Get-employee。 所有數據庫操作都應該由您的DAO來處理。

在您有業務邏輯的情況下,您的代碼可能如下所示。

Employee Bl.ProcessRecord(EmployeeDomain Employee) 
{ 
    //Do some logic.... 
    //Perhaps interact with other DAO operations 
    //Have some business logic operations ETC 
    Persist your changes to the database 
    Employee = DAO.Save-employee(Employee) 
    return Employee; 
} 
相關問題