重構Large Codebehinds - 存儲庫模式和擴展方法

Question

我希望有人可以幫助澄清我的選項，從ASP.NET webforms頁面的代碼隱藏重構方法。作爲背景，最近我們花了一段時間在泛型和非泛型意義上實現存儲庫模式，這使得我們能夠將大量的DAL方法移出代碼隱藏，這非常棒。

我正在努力完成的是一種將應用程序邏輯方法從代碼隱藏中移出的明智方法，該方法專門關注存儲庫/ DAL以及如何最好地構建BL類。

這裏是我正在考慮在目前兩個選項：

1.創建每代碼隱藏，並從該業務邏輯類，揭露像getProject(int id) 方法這將在幕後， 訪問repo.GetById(int id)存儲庫實例

據我可以看到會是以下的這個好處：

• 單獨的應用從codebehinds邏輯，讓他們到b Ë簡單
• 允許在BLL可測試方法（有一些調整），一種已經在MVC控制器類的代名詞（這仍然是儘管WebForms的）
• 不公開庫直接

缺點將是：

• 很多在BLL包裝方法不真正做任何 除了隱藏庫的方法

2.在我的實體類型上寫入擴展方法，例如Project.getUsers()它將訪問一個存儲庫實例方法，允許在不需要特定BLL類的情況下存儲BL，從而減少每個BL類中的包裝方法的重複。

這樣做的好處是：

• 沒有必要有一個BL因爲如此，存儲與他們的實體類型的方法
• 少的包裝方法，因爲不會有需要ProjectBL.getUsers(projectid)和UserBL.getUsers(projectid)這都調用repo.getProjectUsers(projectid)幕後，簡單Project.getUsers()來自codebehinds

這種方法的缺點，只要我可以告訴：

• 如果我將來會引入新的類型，例如'SubProject'getUsers()需要重新加載
• 我並不太熱衷於擴展方法的一般情況，不確定這是否正確使用它們！

我有點不確定哪個是'更好'的做法，或者我錯過了更好的選擇。值得一提的是，知識庫最初是在代碼隱藏中實例化並直接訪問的，但據我所知，這並不理想，因爲我們冒着從存儲庫中返回IQueryable之類的東西的風險，並且使得可以在代碼隱藏中操作的DAL方法產生不一致的結果。

Answer 1

我發現是最有效的使用ASP.NET Web表單的模型是結合/解除綁定模式。在這種模式中，您在代碼隱藏本身中實現的唯一事情是事件處理程序（它將回調更多抽象的，某種類型的BLL中的邏輯較重的方法）以及每種方法將數據從（綁定）和（取消綁定）域對象或DTO的實例。

通過這種方式構建代碼隱藏，代碼隱藏類變成只關心邏輯和表示之間的互操作，因此成爲在大多數情況下相當薄。它將處理的數據將主要是原始數據和DTO，並且不需要任何DAL知識（至少，單個頁面代碼隱藏不會;您可以爲您的代碼隱藏設置您的母版頁或基類，以便有DAL觸摸的方法通常廣泛的網站，基本上使這個基礎類你的控制器層的代碼）。其他

有一點要記住的是，這取決於結構，它可以是非常簡單的單元測試你的代碼隱藏類。你甚至可以TDD他們，一點;標記中的基本GUI元素（以及它們在代碼隱藏中的對象表示）的聲明仍然最好留給IDE，但具有公共可訪問成員的公共代碼隱藏類可以在單元測試中輕鬆實例化，並且公共方法已被執行。

Answer 2

@KeithS我會標記爲接受這一個，因爲沒有其他人似乎有什麼建議！如果您好奇，我選擇了更多的第二種方法，基本上在我的應用程序中，我有一些邏輯「部分」，比如「Projects」或「ApprovalForms」，而我已經爲每個部分創建了一個BL類比每個代碼隱藏一個。

這確實意味着類可以包含它可以是一個位變化的（不是一個單一的目的），但它確實防止我具有噸類與基本上是從一個不同的上下文中訪問相同的方法的方法。這迫使我圍繞存儲庫方法編寫包裝方法，這感覺有點像W.E.T.但這確實意味着我可以提供一種將數據返回到前端的常用方法，從而減少了實現不同實現的機會。