業務邏輯分離

Question

當我在我們的網站中優化我們應用程序的架構時，我遇到了一個問題，我不知道最佳解決方案。

現在，在目前我們有基於此結構的小DLL：

Database <-> DAL <-> BLL 

的dal使用業務對象傳遞給BLL，將它傳遞給使用該DLL的應用程序。

只有BLL是公共的，因此任何包含此dll的應用程序都可以看到bll。

一開始，這對我們公司來說是一個很好的解決方案。 但是，當我們在該Dll上添加越來越多的應用程序時，Bll越大。現在我們不希望某些應用程序可以從其他應用程序中看到Bll邏輯。

現在我不知道最好的解決方案是什麼。

我認爲的第一件事是移動並將bll分隔到其他dll中，我可以將其包含在我的應用程序中。但是，那麼Dal必須是公開的，所以其他的dll可以獲取數據......而且我似乎是一個很好的解決方案。

我的另一個解決方案，就是在不同的命名空間中分隔bll，並且只包含應用程序中需要的命名空間。但是在這個解決方案中，如果你願意，你可以直接訪問其他的bll。

所以我在徵求你的意見。

Answer 1

我同意@MikeC。將名稱空間中的BLL分隔爲每個段。此外，也分開DAL，就像這樣：

• MyCompany.HumanResources.DAL
• MyCompany.Insurance.DAL

另一件事要做的，就是分開DLL的。這樣，你不需要公開DAL。它將成爲每個系統的業務層（如WCF或Web服務），負責BLL和DAL，使支持和維護更容易。我不知道它是否是目前貴公司最經濟實惠的方法（就複雜性而言），但它是一種更好的方法，用於設計目的的。

以前的時間，在這裏開發的應用程序在公司，使用組件結構 - 共享組件槽應用程序 - 。我們意識到，它不是最好的設計，今天許多系統（在生產環境中）都使用這種設計方法。此外：如果您想要更復雜一點，您還可以生成一個通用dbHelper組件，負責維護數據訪問，包括控制連接，命令和事務的操作。這樣，防止重寫的代碼。該組件可以使用企業庫或其他組件。操作例子可能是：

public DbCommand CreateCommand() 
    { 
     if (this._baseCommand.Transaction != null) 
     { 
      DbCommand command = this._baseConnection.CreateCommand(); 
      command.Transaction = this._baseCommand.Transaction; 
      return command; 
     } 
     return this._baseConnection.CreateCommand(); 
    } 

你可以把它虛擬的，實現一個SqlCommand CreateCommand等。

記住：我公開的通用dbHelper的想法，只是一個想法！

Answer 2

你應該爲每個企業的 「片段」 一個獨特的BLL和DAL ...例如：

• MyCompany.HumanResources.BLL
• MyCompany.Insurance.BLL
• MyCompany.Accounting .BLL

Answer 3

我建議你根據它們的相關性（根據之前的文章）將你的業務邏輯分成不同的dll，這些類將實現特定的接口， s界面將在您的企業登錄用戶中聲明。然後，我建議你實現容器（請參閱控制反轉理論）來解決dll實現問題，這將允許您將業務邏輯實現從消耗中分離出來，並且您將能夠毫無困難地用另一個實現替換某個實現。

我捍衛提供商與IoC的使用，而不是直接消耗業務經理類（想想可能導致噩夢的參考）。該解決方案解決了dll的隔離問題和優化的消耗。

Answer 4

這聽起來像你有共同的業務邏輯，它通常適用於你的組織，而每個部門或部門更具體的邏輯。你可以設置你的代碼，以便每個部門。只取決於它們的具體邏輯，後臺使用「基本」邏輯中的任何通用功能。爲此，您可以設置以下項目：

• Business.BLL
• Business.Finance.BLL
• Business.IT.BLL
• （等等，循環往復，等等。 ..）

請注意，它們中的每一個都可以是單獨的項目，它可以編譯爲自己的程序集。一個部門只需要使用他們自己的程序集。

就數據訪問而言，您可以在基本BLL中使用通用數據訪問例程。您的特定BLL可以將自己的專用數據查詢集中到基本BLL中，然後使用通用DAL並將結果返回到鏈中。