即。 当MVC不是一个选项时，MVP仍然是下一个最佳选择吗？
我想我会在这里问这个问题，因为我确信还有像我这样的其他人没有奢侈品参与绿地项目并希望重构webforms UI以更好地分离演示文稿和商业对象...
我正在开发一个遗留应用程序，其任务是添加相对较少的附加要求，增强功能和错误修复。
我在这里讨论的应用程序部分可能被描述为一组CRUD操作的UI，这些操作是持久存储到关系数据库的业务对象。
现有UI使用MultiView控件在关联业务对象（一对一关联或一对多/父子对象）的编辑之间进行导航。是的，这是对的 - 所有这一切都在一页上。不幸的是，UserControls的使用非常少，所以标记和代码隐藏的时间长达数百行。
在每个View上，FormView通过各种ObjectDataSource管理业务对象上的CRUD。在每个FormView的ItemTemplate中，各种服务器控制数据绑定到ObjectDataSource上的字段或方法。
我想引入更多关注点分离，并从页面代码隐藏中获取一些代码。
到目前为止，我的研究表明我可能会考虑：
Use a flavour of Model View Presenter;更具体地说 - use an ObjectContainerDataSource from the Web Client Software Factory可以更容易地在当前UI和一组新的Presenter类之间架起桥梁。
使用MVC框架（不是选项）从头开始构建。
独自留下;如果我需要在不同的UI场景中重用我的演示文稿，MVP模式是否合理？
如果我满意（3）我仍然想知道如何开始重构以更好地分离演示文稿。
你会做什么？感激地收到任何其他想法......
以下是有兴趣的人的更多背景信息：
该域名在药物研究领域，但这是相当无关紧要的，您可以将其视为非常典型的业务线 - 一系列设置的用户配置，这些设置构成了应用程序另一部分的操作条件。
业务对象层已经以非常一致的方式构建。虽然我可能不喜欢它，但我无法证明改变它是正确的。每个对象都是它自己的存储库/数据访问对象，因为存在“按ID获取”和“按标准获取列表”的静态方法。在可能的情况下，常见操作在抽象基类中实现。每个业务对象都将数据访问工作委托给数据访问层，该数据访问层利用ADO.NET 2.0 Provider Factory机制来保持与具体Provider相对抽象。在这方面，它与使用Microsoft企业库中的数据访问应用程序块的任何应用程序共享很多共同点。
在NUnit中编写了相当详尽的集成测试，它们从头开始设置测试数据库，因此它们需要花费很长时间才能运行，但至少他们会验证这些内容是否正常工作（无论如何在过去的某些时候;-)。几乎没有真正的单元测试（还）。
答案 0 :(得分：3)
WebForms现在以ASP.NET Web Forms MVP project
的形式出现了新的努力“......还有很多人 ASP.NET Web引人注目的优势 形式。
ASP.NET Web Forms MVP项目是 ......一种方便的方法 关注点和可测试性的分离 同时保持快速 构建Web窗体的开发 提供“
Rob Conery has concerns这可能是一种浪费的努力和不必要的分心，因为我们有MVC，但在这个阶段我仍然认为源代码值得一看......
答案 1 :(得分：2)
http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx有一个用webforms做MVP的好例子。优势不仅在于您的UI与BL分离 - 真正的好处是您可以为代码编写测试。