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

Question

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

我想我会在这里问这个,因为我确信还有像我这样的其他人没有奢侈品参与绿地项目,并希望重构webforms UI以更好地分离演示文稿和业务对象. .

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

我在这里解决的应用程序部分可能被描述为一组CRUD操作的UI,这些操作是持久存储到关系数据库的业务对象.

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

在每个View上,FormView通过各种ObjectDataSource管理业务对象上的CRUD.在每个FormView的ItemTemplate中,各种服务器控制数据绑定到ObjectDataSource上的字段或方法.

我想引入更多的关注点分离,并从页面代码中获取一些代码.

到目前为止,我的研究建议我可以考虑:

1. 使用Model View Presenter的风格 ; 更具体地说 - 使用Web客户端软件工厂中的ObjectContainerDataSource,可以更轻松地在当前UI和一组新的Presenter类之间进行桥接.

2. 使用MVC框架(不是选项)从头开始构建.

3. 别管; 如果我需要在不同的UI场景中重用我的演示文稿,MVP模式是否合理？

如果我满意(3)我仍然想知道如何开始重构以更好地分离演示.

你会怎么做？感恩的任何其他想法......

---

这里有一些感兴趣的人的背景:

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

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

在NUnit中编写了相当详尽的集成测试,它们从头开始设置测试数据库,因此它们需要很长时间才能运行,但至少他们会验证这些内容是否正常工作(无论如何在过去的某些时候;-).几乎没有真正的单元测试(还).

Answer 1

http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx有一个使用 Webform 进行 MVP 的好例子。优点不仅仅是你的 UI 与 BL 解耦 - 真正的好处是你可以为代码编写测试。