asp.net - 重构旧版 WebForms 应用程序以更好地分离关注点

Question

即当 MVC 不是一个选项时，MVP 仍然是下一个最佳选择吗？

我想我会在这里问这个问题，因为我敢肯定还有其他像我这样的人没有机会参与一个新项目，并且想要重构 Web 表单 UI 以更好地分离表示与业务对象。 .

我正在开发一个遗留应用程序，其任务是添加相对较小的附加要求、增强功能和错误修复。

我在这里处理的应用程序部分可能被描述为一组对持久到关系数据库的业务对象的 CRUD 操作的 UI。

现有 UI 使用 MultiView 控件在关联业务对象(一对一关联或一对多/父子)的编辑之间导航。是的，没错 - 都在一页上。不幸的是，用户控件的使用非常少，因此标记和代码隐藏长达数百行。

在每个 View 上，FormView 通过各种 ObjectDataSource 管理业务对象上的 CRUD。在每个 FormView 的 ItemTemplate 中，各种服务器控件数据绑定(bind)到 ObjectDataSource 上的字段或方法。

我想介绍更多的关注点分离，并从 Page 代码隐藏中获取一些代码。

到目前为止，我的研究表明我可能会考虑:

Use a flavour of Model View Presenter ;更具体地说 - use an ObjectContainerDataSource from the Web Client Software Factory使当前 UI 和一组新的 Presenter 类之间的桥梁更容易。

使用 MVC 框架从头开始重新构建(不是一个选项)。

别管闲事；只有当我需要在不同的 UI 场景中重用我的演示文稿时，MVP 模式才合理？

如果我同意(3)，我仍然想知道如何开始重构以更好地分离表示。

你会怎么办？任何其他想法都感激不尽...

这里有更多的背景知识供有兴趣的人引用:

该领域属于药物研究，但这无关紧要，您可以将其视为非常典型的业务线——一系列设置的用户配置，这些设置构成了应用程序另一部分的操作条件。

业务对象层已经以非常一致的方式构建。虽然我可能不喜欢它，但我不能证明改变它是合理的。每个对象都是它自己的存储库/数据访问对象，因为有“按 ID 获取”和“按标准获取列表”的静态方法。在可能的情况下，通用操作在抽象基类中实现。每个业务对象都将数据访问工作委托(delegate)给数据访问层，该层利用 ADO.NET 2.0 Provider Factory 机制保持与具体 Provider 的相对抽象。在这方面，它与使用 Microsoft 企业库中的数据访问应用程序 block 的任何应用程序有很多共同之处。

有相当详尽的用 NUnit 编写的集成测试，它们从头开始设置测试数据库，因此它们需要很长时间才能运行，但至少它们验证了这些东西是否可以正常工作(无论如何，在过去的某个时间点 ;-)。几乎没有真正的单元测试到位(还)。

Answer 1

WebForms 现在正在以 ASP.NET Web Forms MVP project 的形式出现。

"...there are still a host of compelling advantages to ASP.NET Web Forms.

The ASP.NET Web Forms MVP project is ... an approach that facilitates separation of concerns and testability whilst maintaining the rapid development that Web Forms was built to deliver"

Rob Conery has concerns既然我们有了 MVC，这可能是一种浪费的努力和不必要的分心，但在这个阶段我仍然认为源代码值得一看......