我正在開發一個使用MVC3和實體框架的應用程序。它是一種三層方法，具有Web服務器中承載的表示層以及應用服務器中的業務層和數據訪問層。我們沒有將對象上下文暴露給表示層或業務層。對象上下文僅包含在數據訪問層中，並將數據訪問和數據持久性公開爲數據訪問層方法（即數據訪問邏輯僅在數據訪問層中分離和實現）的功能。業務層正在調用數據訪問層方法並將數據返回到表示層。3層體系結構的分層應用程序的良好實現方法？
我擔心的大部分業務層方法只是爲了訪問數據，它只是將調用轉發到數據訪問層而不進行任何操作。所以我們在這兩個層重複代碼。我們還有其他更好的方法來避免這種重複嗎？
以分層方式實現業務層中的數據訪問邏輯是否是一種很好的做法？
有人可以提出一個很好的分層應用與3層架構的實現方法嗎？
我不認爲它一定不好重複邏輯分離的代碼。時間到了，這將取得成功。假設您將由Oracle替換SQL服務器。或者微軟將提出Linq 2.0，並且一些實現將會改變。您將感謝您將它分開，而那些從業務層調用數據庫的人將不得不在兩個地方進行修改 - DAL和BLL。 它的價值。但是，再次，沒有正確的答案，直到實用性，可用性，便利性，並且最重要的是使其符合其目的。
希望這有幫助。
如果您發現自己的業務層所做的只是將調用委託給數據訪問層，那麼這就表明該業務層對您的應用程序可能不是必需的，因爲它沒有帶來額外的價值。您可以擺脫它，並讓控制器直接與數據訪問層進行對話（通過當然的抽象） - 這就是大多數教程中顯示的EF數據上下文。
在那些主要由CRUD操作簡單的應用程序，業務層可能沒有必要。隨着應用程序的增長的複雜性，你可能會決定晚些時候推出，但不從一開始就做太多的抽象，特別是如果這些抽象不給您帶來任何額外的價值。
如前所述沒有「正確」的方式來設置的東西了。多年來，我發現了幾件事情，幫助我決定採取哪種方法。
兩個層次
如果你的店是存儲過程重了很多數據庫程序員，而且往往把業務邏輯在數據庫中，然後用一個兩層的做法去。在這種情況下，你會發現你的業務層通常只是調用數據層。另外，如果你的代碼庫和頁面往往很小，你永遠不會重複功能，那麼採用兩層的方法。您將節省大量的時間。
三層
如果你的店鋪喜歡在代碼中的很多業務邏輯的和重複的是，邏輯處處然後用三層去。即使您注意到很多業務層只是調用數據層，隨着時間的推移，當您添加功能時，隨着時間的推移，只需將代碼添加到業務層中就簡單多了。另外，如果你有大量的代碼庫和大量的重複邏輯的頁面，那麼我肯定會採用這種方法。
我在我的工作中在我們的企業級應用程序中找到了兩者的混合物。有問題的領域是使用動態sql（gag）並且反覆重複業務邏輯的領域。我在重構時發現，我將這些代碼拉入3層架構，併爲將來節省大量時間，因爲我可以重用它。
對你有幫助嗎？ –