是2層和3層架構的混合架構推薦

Question

我正在製作一個Web應用程序，它將各種業務規則作爲輸入並將它們存儲在數據庫中。這是使用3層架構完成的。

之後，我必須在單個操作中使用所有這些業務規則，因此我正在爲Stored Procedure編寫此部分的業務邏輯，並從UI中調用它，使其成爲2層。

由於這是一種罕見的情況，所有數據（這是一個相當大的數量 - SP本身需要大約6分鐘的處理時間）是單個操作所需要的，並且我無法獲取所有數據作爲進入BLL的對象，僅僅是爲了保持建築的完整性。 SP中的邏輯也是迭代的，因此所有的數據都需要在BLL中維護，並且不能有條件地獲取。

如果我有正確的方法，請給我建議。

Answer 1

@APC是正確的，邏輯應該住的地方是最合適的 - 和：

• 的UI還是應該經過BL層得到的數據，讓您的應用程序一致的結構。
• 如果你將在應用程序的不同位置有邏輯（爲了滿足某些要求，比如性能），你應該清楚地記錄那些控制因素，並且對於後續開發人員來說應該很容易。

兩個選項浮現在腦海中（關於結構）：

• 的一種方式，以確保應用程序結構合理，並且清楚的是接口分離特定的「繁重」的任務。理想情況下，您的所有數據訪問都應該已經被接口抽象出來，並且應該將其分解爲邏輯區域（請參閱Interface Segregation Principle - ISP）。因此，您可以爲特定的數據訪問需求提供專用接口：[BL] - > [IDataAccess] - > [具體數據訪問]
• 另一種方法（但是也有類似的情況）：不是讓BL訪問這些特殊數據像常規數據訪問一樣調用，將其包含或注入爲BL。

你如何做第二種方法：定義一個接口（在BL層中）將被其他業務對象使用：[BL Object] - > [ISpecialBusinessLogic] - > [具體實現]。具體的業務邏輯可以是任何東西 - 但在你的情況下，它將是一個特殊的數據訪問方法/組件的調用，你可以在其中執行「重負」操作。

當您實現數據訪問時，您可以選擇在單個類/組件（實現多個接口）或單獨實現單個接口的類/組件中執行所有操作。

Answer 2

業務邏輯屬於最合適的地方。如果你有與數據相關的邏輯，而且這些邏輯只能通過存儲過程執行，那麼數據庫就是保存它的合適位置。

Answer 3

我假設你的應用程序的其他模塊也保持3連接體系結構。所以爲了保持一致性和可維護性，您應該維護3層架構。此外，如果您將來需要對SP返回的數據應用一些業務邏輯，那麼您將在BL中執行此操作。