重构大型代码隐藏 - 存储库模式和扩展方法

Question

我希望有人可以帮助澄清我从ASP.NET网页表单中代码隐藏重构方法的选项。

作为背景，我们最近花了一些时间在通用和非通用意义上实现存储库模式，这使我们能够将很多DAL方法移出代码隐藏，这很棒。

我正在努力最终确定的是将应用程序逻辑方法移出代码隐藏的合理方法，特别关注存储库/ DAL以及如何最好地构建BL类。

以下是我目前正在考虑的两个选项：

1.为每个代码隐藏创建一个Business Logic类，并从中公开         幕后的getProject(int id)等方法，         访问repo.GetById(int id)

的存储库实例

据我所知，这样做的好处如下：

• 从代码隐藏中分离应用程序逻辑，使它们变得简单
• 在BLL中允许可测试的方法（有一些调整），与MVC中的控制器类同义（虽然这仍然是webforms）
• 不直接公开存储库

缺点是：

• BLL中的许多包装器方法并没有真正做任何事情 除了隐藏存储库方法

2.在我的实体类型上编写扩展方法，例如Project.getUsers()将访问存储库实例方法，允许存储BL而无需特定的BLL类，从而减少每个BL类中包装器方法的重复。

这样做的好处是：

• 不需要像这样存储BL，存储具有实体类型的方法
• 减少包装方法，因为不需要ProjectBL.getUsers(projectid)和UserBL.getUsers(projectid)在幕后调用repo.getProjectUsers(projectid)，从两个代码隐藏中调用简单Project.getUsers()

据我所知，其缺点是：

• 如果我将来推出新类型，例如“子项目”getUsers()需要重新启用
• 我一般不太热衷于扩展方法，也不确定这是否适合使用它们！

我有点不确定哪种'更好'的做法，或者我是否错过了一个更好的选择。可能值得知道的是，最初存储库是在代码隐藏中实例化并直接访问的，但是据我所知，这并不理想，因为我们冒险从存储库返回诸如IQueryable之类的东西并制作可以在代码隐藏中操作的DAL方法产生不一致的结果。

Answer 1

我发现使用ASP.NET Webforms最有效的模型是绑定/解除绑定模式。在这种模式中，你在代码隐藏中实现的唯一事情是事件处理程序（它将在某种BLL中回调更抽象，逻辑重的方法）和一个方法，每个方法从（Bind）传递数据到（取消绑定）域对象或DTO的实例。

通过以这种方式构造代码隐藏，代码隐藏类只关注逻辑和表示之间的互操作，因此在大多数情况下变得非常薄。它将处理的数据将主要是原语和DTO，并且它不需要任何DAL知识（至少，单个页面代码隐藏不会;您可以为您的代码隐藏设置主页或基类具有DAL触摸方法，通常用于网站的大范围，基本上使这个基类成为代码中的Controller层。

要记住的另一件事是，根据结构，对代码隐藏类进行单元测试非常简单。你甚至可以将它们TDD到某一点;标记中的基本GUI元素的声明（以及它们在代码隐藏中的对象表示）仍然最好留给IDE，但是可以在单元测试中容易地实例化具有可公开访问的成员的公共代码隐藏类，并且公共方法被执行

Answer 2

@KeithS我打算将此标记为已被接受，因为似乎没有其他人有任何建议！如果你好奇我选择了更多的第二种方法，基本上在我的应用程序中我有一些逻辑“部分”，如'Projects'或'ApprovalForms'，我已经去了每个部分创建一个BL类而不是每个代码隐藏一个以上。

这确实意味着该类可以包含可能有点变化的方法（不是单一目的），但它确实阻止了我使用从不同上下文访问的基本相同方法的大量类。它迫使我围绕存储库方法编写包装器方法，感觉有点W.E.T.但这确实意味着我可以提供一种将数据返回到前端的通用方法，从而减少实现不同的可能性。