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

发布于 2024-08-12 11:16:57 字数 1588 浏览 2 评论 0原文

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

我想我应该在这里问这个问题，因为我确信还有像我这样的人没有奢侈的选择一个绿地项目，想要重构 Webforms UI 以更好地分离演示文稿与业务对象...

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

我在这里讨论的应用程序部分的特征可能是针对持久保存到关系数据库的业务对象的一组 CRUD 操作的 UI。

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

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

我想引入更多的关注点分离，并从 Page 代码隐藏中获取大量代码。

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

使用模型视图的风格演示者；更具体地说 - 使用 Web 客户端软件工厂中的 ObjectContainerDataSource 可以更轻松地在当前 UI 和一组新的 Presenter 类之间建立桥梁。
使用 MVC 框架再次从头开始构建（不是一个选项）。
别管它；仅当我需要在不同的 UI 场景中重复使用我的演示文稿时，MVP 模式才合理？

如果我选择（3），我仍然想知道如何开始重构以更好地分离表示。

你会做什么？感谢任何其他想法...

对于任何感兴趣的人来说，这里有更多背景知识：

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

业务对象层已经以非常一致的方式构建。尽管我可能不喜欢它，但我不一定有理由改变它。每个对象都是它自己的存储库/数据访问对象，因为有“按 ID 获取”和“按条件获取列表”的静态方法。在可能的情况下，公共操作在抽象基类中实现。每个业务对象将数据访问工作委托给数据访问层，该数据访问层利用 ADO.NET 2.0 提供程序工厂机制来保持对具体提供程序的相对抽象。在这方面，它与使用 Microsoft 企业库中的数据访问应用程序块的任何应用程序有很多共同点。

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

原文

i.e. Is MVP still the next best choice when MVC is not an option?

I thought I'd ask this here as I'm sure there are others like me who don't have the luxury of being on a green-field project and want to refactor a webforms UI to better separation of presentation from business objects...

I'm working on a legacy application tasked with adding relatively small additional requirements, enhancements, and bug fixes.

The part of the application I'm addressing here may be characterised as the UI for a set of CRUD operations over business objects that are persisted to a relational database.

The existing UI uses a MultiView control to navigate between the editing of associated business objects (one-one associations or one-many / parent-child). Yes, that's right - all on one page. Unfortunately there is very sparing use of UserControls so the markup and code-behind is hundreds of lines long.

On each View a FormView manages the CRUD over the business objects via various ObjectDataSources. Within the ItemTemplate of each FormView various server controls databind to fields or methods on an ObjectDataSource.

I'd like to introduce more separation of concerns and get some of the reams of code out of Page code-behind.

My research so far suggests to me that I might consider:

Use a flavour of Model View Presenter; more specifically - use an ObjectContainerDataSource from the Web Client Software Factory to make it easier to bridge between the current UI and a set of new Presenter classes.
Build again from scratch with an MVC framework (not an option).
Leave well alone; an MVP pattern is only justified if I need to re-use my Presentation in different UI scenarios?

If I settle with (3) I'd still like to know how to start refactoring towards better separation of presentation.

What would you do? any other ideas gratefully received...

Here's some more background for anyone who's interested:

The domain is in pharmaceutical research but that's fairly irrelevant and you can think of it as pretty typical line-of-business - user configuration of a family of settings that form the operating conditions of another part of the application.

The business object layer has already been built in a very consistent manner. Although I may not like it, I can't neccesarily justify changing it. Each object is it's own Repository / Data Access Object in that there are static methods for 'get by ID' and 'get list by criterion'. Where possible common operations are implemented in an abstract base class. Each business object delegates the data access work to a Data Access Layer that makes use of ADO.NET 2.0 Provider Factory mechanisms to remain relatively abstracted from a concrete Provider. In this respect it shares a lot in common with any app that uses the Data Access Application Block from the Microsoft Enterprise Library.

There are fairly exhaustive integration tests written in NUnit that set up a test database from scratch so they take ages to run but at least they verify that stuff works as it should (at some point in the past anyway ;-). There is almost no true unit testing in place (yet).

分享到QQ

分享到微博