asp.net webforms应用中的重构技术

Question

我正在开发一个用asp.net web表单编写的大型应用程序。它是在asp.net 1.0下开发的，虽然部分已经更新，但仍然使用DataGrid。

大多数代码驻留在代码隐藏中，或者位于无法在运行的IIS之外实例化的控制器类中。(我们使用的控制器框架提供与会话状态相关联的生存期管理。)数据访问是通过自定义DAL进行的，这意味着大部分代码还需要一个包含适当数据的活动数据库。

我希望将代码与数据库和web服务器分离开来，这样我就可以在测试工具下运行它。有什么好的策略可以从这类代码转移到更可测试的结构吗？

Answer 1

最好的方法是将代码重构到逻辑层(服务、DAO/Repository等)。看看Model演示者如何抽象其他内容的想法，但现实地说，这样的努力通常通过正确重写更好；从经验来看，当WebForms做得很糟糕时，很难重构它，很有可能你不得不重写太多东西，基本上是在重写它。

Answer 2

问题是。根据你给出的信息，理论上可能的答案范围是无限的。

如果我收集确凿的事实，我会得到以下图片：

• ASP.NET 1.0 Webform
• DataGrid
• 紧耦合
• 通过自定义DAL访问数据

除此之外，你并没有说你的重构是朝着哪个方向发展的。简单地清理烂摊子是一个很好的起点，但还不够。正如韦恩指出的那样:它最终会有效地改写。

至少有两种可能性：

1)在温泉中，您拥有一个智能的前端，并且在前端执行大部分(或至少是很好的)逻辑。

2)利用WebAPI开发了一个传统的web应用程序。此外，虽然我实际上没有使用过它，但也许值得一看：NancyFX

根据您的应用程序/代码库的大小以及您想要的时髦程度，您应该考虑使用微服务。

一些简单的建议是：

• 用JS-等效：datatables.net或jqGrid替换数据栅格

数据访问是通过自定义DAL进行的，这意味着大部分代码还需要一个包含适当数据的活动数据库。

• 这可能会被嘲弄或抹掉

至于其余的，则取决于：

如果代码基是以某种方式形成的。试试看，代码是干什么用的。写个测试。看看你的假设是否成立。如果是的话，编写另一个测试，以验证另一个假设。如果皮塔因素太高，则完全重写业务逻辑。否则，重复并构建对代码的迭代、精细化的理解，并演化出一个细粒度的测试套件。一步一步，你正在编织一个安全网络围绕着代码。如果它足够紧，拿起电锯，把代码切成小块。

我必须承认，这是一个非常普遍的建议，但如果不进一步了解你的代码基，就很难给出任何具体的建议。