1

在設計一個新的多層應用程序,我面臨的困難在決定爲我的DALBLL層設計單/多數據存儲庫。設計DAL和BLL - 對相關表

假設我將員工信息分散在多個表中,這些表具有與主表的1-1和1-多關係。很少有如下所列:

員工(主表),
Employee_Contact_Detail,
Employee_Education,
Employee_Skill,
Employee_Experience

在DAL水平,我有一個通用的數據存儲庫提供諸如GETALL常用功能, GetSingle,添加,編輯,刪除每個表。

現在,我要設計我的「員工資料庫」從我的「通用數據倉庫」派生並添加功能像GetEmployeePersonalDetail,GetEmployeeContactDetail,GetEmployeeEducation,AddEmployeePersonalDetail,EditEmployeePersonalDetail等單一類上面列出在這所有相關表對於「通用數據存儲庫」,我將獲得的好處更少。另一種方法是我爲每個表創建(並從Generic Repository派生)一個單獨的數據存儲庫,然後在「Employee」的業務邏輯層創建一個類。

編輯

如果我去了選項「爲每個表單獨的數據存儲庫」,在DAL水平,然後,而不是「單一的商業邏輯類」的「僱員」,如果我創建獨立的業務邏輯與每個數據存儲庫相對應的類是否會採取不雅的方法來觀察場景?

非常感謝您的指導。

+0

你打算做什麼沒有錯。這個問題沒有任何具體的答案。所有答案都將基於意見。所以,你最好關注你的需求而不是模式。模式可以解決我們的問題。如果有什麼解決你的問題,那麼這是你的模式。 –

+0

@A_J,非常感謝您的意見。我已經提出了一些問題。 – developer

回答

1

正如您在提問中所提到的,這是我的看法。

問題:

如果你已經有了基礎信息庫,爲什麼每個表創建特定的倉庫?再次,在BLL中,您正在爲每個存儲庫創建單獨的Service類(如您所述的「業務邏輯類」)。這是一件重複的工作,難以管理和理解。

建議:

您還沒有提到什麼ORM(如果有的話),你正在使用;所以我假設你的ORM提供了實現下面架構的必要功能。
我建議你在通用存儲庫關閉你的DAL。不要爲特定的表編寫DAL類。您的所有服務類都將使用通用DAL來執行基本的CRUD功能。所有擴展功能都應該在Service類中實現。

關於服務類,而不是爲每個存儲庫/表創建一個類是再次重複的工作。在一個服務中更好地分組您的相關多個表(參考以上段落時存儲庫無疑)。

例如,您可以創建通用DAL,爲所有表提供基本功能。您創建EmployeeService,涵蓋所有與員工相關的表格。您創建了覆蓋所有會計相關表的AccountService。同樣,LogService適用於所有與伐木有關的活動。當你在一個類中獲得所有相關成員時,這使得與服務交互變得容易。這也減少了重複工作。

請參閱我的thisthis問題及其接受的答案。

我希望這能解釋您的擔憂。

編輯1

正如您的評論中提到,你我們EF。它支持實現我所建議的必要功能。

實現在BLL代替DAL擴展功能將重疊層角色

是;它確實如此。其他方面也是一樣的。當您爲每個表格編寫DAL時,實際上是在DAL中泄漏業務邏輯。如果業務邏輯發生任何變化,則需要修改無意義的DAL。
在我的建議中,即使圖層重疊,關注點仍然是分開的。 DAL僅處理CRUD。 BLL處理包括數據庫邏輯的所有邏輯。

您是否在任何項目中使用過相同的策略?

是的。在之前的一些項目中,我爲每個表格創建了單獨的DAL,而不是通用的DAL。這導致了巨大的重複工作。儘管項目相對較小,但維護開銷更大。幾個月前,我開始進行一個相對較大的項目,在那裏實施了我上面提出的建議。我們現在可以看到給我們的救濟。

+0

謝謝你的建議,這似乎很有用;編碼少,併發症少。我唯一擔心的是,在BLL而不是DAL中實現擴展功能將重疊層角色,並且我不確定項目的增長能否繼續使用相同的策略而沒有任何複雜性。你有沒有在你的任何項目中使用相同的策略?順便說一句,我正在使用EF6。 – developer

+0

非常感謝您分享您的經驗給我更多的信心。 – developer