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

Question

我希望有人可以帮助阐明我关于从 ASP.NET webforms 页面的代码隐藏重构方法的选项。

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

我正在努力最终确定的是一种将应用程序逻辑方法移出代码隐藏的明智方法，代码隐藏具体侧重于存储库/DAL 以及如何最好地构建 BL 类。

以下是我目前正在考虑的两个方案:

1.为每个代码隐藏创建一个业务逻辑类，并从中公开 像 getProject(int id) 这样的方法会在幕后， 访问 repo.GetById(int id)

的存储库实例

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

• 将应用程序逻辑与代码隐藏分开，使它们变得简单
• 允许在 BLL 中使用可测试的方法(进行一些调整)，类似于 MVC 中的 Controller 类(虽然这仍然是网络表单)
• 不直接公开存储库

缺点是:

• BLL 中的许多包装器方法实际上什么都不做除了隐藏存储库方法

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

这样做的好处是:

• 不需要这样的 BL，存储方法及其实体类型
• 更少的包装器方法，因为不需要 ProjectBL.getUsers(projectid) 和 UserBL.getUsers(projectid)，它们都调用 repo .getProjectUsers(projectid) 在幕后，来自两个代码隐藏的简单 Project.getUsers()

据我所知，这样做的缺点是:

• 如果我将来引入新类型，例如'SubProject' getUsers() 需要重新实现
• 我不太热衷于一般的扩展方法，不确定这里是否是使用它们的正确位置!

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

Answer 1

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

通过以这种方式构建代码隐藏，代码隐藏类变得只关心逻辑和表示之间的互操作，因此在大多数情况下变得非常精简。它将处理的数据主要是原始数据和 DTO，并且不需要任何 DAL 知识(至少，单个页面代码隐藏不需要；您可以为您的代码隐藏设置您的母版页或基类以有广泛的站点通用的 DAL 接触方法，基本上使这个基类成为代码中的 Controller 层)。

要记住的另一件事是，根据结构，对代码隐藏类进行单元测试可能非常简单。在某种程度上，您甚至可以对它们进行 TDD；标记中基本 GUI 元素的声明(以及它们在代码隐藏中的对象表示)仍然最好留给 IDE，但是可以在单元测试中轻松实例化具有可公开访问成员的公共(public)代码隐藏类，并且可以使用公共(public)方法.