即当 MVC 不是一个选项时，MVP 仍然是下一个最佳选择吗？
我想我会在这里问这个问题，因为我敢肯定还有其他像我一样的人没有机会参与一个新建项目，并且想要重构 Web 表单 UI 以更好地将表示与业务对象分离。 .
我正在开发一个遗留应用程序，其任务是添加相对较小的附加要求、增强功能和错误修复。
我在这里处理的应用程序部分可能被描述为一组对持久保存到关系数据库的业务对象的 CRUD 操作的 UI。
现有 UI 使用 MultiView 控件在关联业务对象（一对一关联或一对多/父子）的编辑之间导航。是的，没错 - 都在一页上。不幸的是，用户控件的使用非常少，因此标记和代码隐藏长达数百行。
在每个 View 上，FormView 通过各种 ObjectDataSource 管理业务对象上的 CRUD。在每个 FormView 的 ItemTemplate 中，各种服务器控件数据绑定到 ObjectDataSource 上的字段或方法。
我想介绍更多的关注点分离，并从 Page 代码隐藏中获取一些代码。
到目前为止，我的研究表明我可能会考虑：
使用 Model View Presenter 的风格；更具体地说 -使用 Web 客户端软件工厂的 ObjectContainerDataSource可以更轻松地在当前 UI 和一组新的 Presenter 类之间建立桥梁。
使用 MVC 框架从头开始重新构建（不是一个选项）。
别管闲事；只有当我需要在不同的 UI 场景中重用我的演示文稿时，MVP 模式才合理？
如果我同意（3），我仍然想知道如何开始重构以更好地分离表示。
你会怎么做？任何其他想法都感激不尽...
这里有更多的背景知识供有兴趣的人参考：
该领域属于药物研究领域，但这无关紧要，您可以将其视为非常典型的业务线——一系列设置的用户配置，这些设置构成了应用程序另一部分的操作条件。
业务对象层已经以非常一致的方式构建。虽然我可能不喜欢它，但我不能证明改变它是合理的。每个对象都是它自己的存储库/数据访问对象，其中有“按 ID 获取”和“按标准获取列表”的静态方法。在可能的情况下，通用操作在抽象基类中实现。每个业务对象都将数据访问工作委托给数据访问层，该层利用 ADO.NET 2.0 提供者工厂机制保持相对于具体提供者的抽象。在这方面，它与使用 Microsoft 企业库中的数据访问应用程序块的任何应用程序有很多共同之处。
有相当详尽的用 NUnit 编写的集成测试，它们从头开始设置测试数据库，因此它们需要很长时间才能运行，但至少它们验证了这些东西是否可以正常工作（无论如何，在过去的某个时间点 ;-)。几乎没有真正的单元测试到位（还）。