具有三層體系結構的分層應用程序的良好實現方法？

Question

我正在使用MVC3和Entity Framework開發應用程序。 它采用三層方法，將表示層托管在Web服務器中，並將業務層和數據訪問層托管在Application Server中。 我們沒有將對象上下文暴露給表示層或業務層。 對象上下文僅包裝在數據訪問層中，並且將數據訪問和數據持久性作為數據訪問層方法的功能公開（即，數據訪問邏輯僅在數據訪問層中分離和實現）。 業務層正在調用數據訪問層方法，並將數據返回到表示層。

我擔心的是，大多數業務層方法僅用於訪問數據，而只是將呼叫轉發到數據訪問層而無需任何操作。 因此，我們在兩層中都重復了代碼。 我們還有其他更好的方法來避免這種重復。

以分層方式在業務層中實現數據訪問邏輯是一種好習慣嗎？

有人可以為采用三層體系結構的分層應用程序提出一種好的實現方法嗎？

Answer 1

如果您發現自己的業務層所做的只是將調用委派給數據訪問層，則表明該業務層可能對您的應用程序不是必需的，因為它沒有任何附加價值。 您可以擺脫它，並讓控制器直接與數據訪問層對話（當然是通過抽象）-這就是那里的大多數教程與EF數據上下文一起顯示的內容。

在主要由CRUD操作組成的簡單應用程序中，可能不需要業務層。 隨着應用程序復雜性的增加，您可能決定稍后再引入它，但是從一開始就不要做太多抽象，特別是如果這些抽象不會給您帶來任何額外的價值。

Answer 2

如前所述，沒有“正確”的方式進行設置。 這些年來，我發現了一些可以幫助我決定采用哪種方法的東西。

兩層

如果您的商店存儲過程繁瑣，並且數據庫程序員很多，並且傾向於將業務邏輯放入數據庫中，則可以采用兩層方法。 在這種情況下，您會發現您的業務層通常只是在調用數據層。 另外，如果您的代碼庫和頁面往往很小，並且您從不重復功能，則可以采用兩層方法。 您將節省大量時間。

三層

如果您的商店喜歡在代碼中包含大量業務邏輯，並且該邏輯在各處重復存在，則可以采用三層結構。 即使您注意到很多業務層只是在調用數據層，添加功能也會隨着時間的推移而發現，將代碼添加到業務層要容易得多。 另外，如果您的代碼庫很大，並且頁面數不勝數，並且包含很多重復的邏輯，那么我肯定會采用這種方法。

我在工作中在企業級應用程序中發現了兩者的混合體。 有問題的領域是使用動態sql（gag）並一遍又一遍地重復業務邏輯的領域。 我在重構時發現，我將這段代碼放入3層體系結構中，並在將來節省了很多時間，因為我可以重復使用它。

Answer 3

我認為復制邏輯分離的代碼不一定不好。 這將有回報的時候到了。 假設您將用Oracle替換SQL Server。 否則，Microsoft將提出Linq 2.0，並且某些實現會發生變化。 您將感謝您將其分開，而那些從業務層直接調用數據庫的人將不得不在兩個地方進行修改-DAL和BLL。 物有所值。 但同樣，對於實用性，可用性，便利性，沒有正確的答案，最重要的是要使其符合其目的。

希望這會有所幫助。