重构ASP.NET 2.0应用程序更“现代”

Question

这是一个假设情景。假设您刚刚在一家拥有小型开发团队的公司工作过。该公司使用.NET 2.0编写的内部CRM / ERP类型系统来管理所有日常事务（让我们简化并说出客户帐户和记录）。该应用程序是在几年前编写的，当时.NET 2.0刚刚推出并使用以下架构设计：

• Web表单
• 数据层是围绕调用存储过程的SqlCommand的瘦包装器
• 通过sprocs填充的基本DTO样式业务对象
• “业务逻辑”层，充当webform和数据库之间的网关（即调用该层后面的代码）

让我们说，随着应用程序中添加了更多更改和要求，您开始觉得旧架构正在显示其年龄，并且变更越来越难以实现。您将如何引入重构步骤A）使应用程序现代化（即正确分离关注点）和B）确保应用程序能够轻松适应组织中的变化？

IMO的变化将涉及：

• 将Linq等ORM引入Sql并删除CRUD的sproc
• 假设你不能抛弃Webforms，将M-V-P模式引入表单
• 确保网关类符合SRP和其他SOLID原则。
• 将重用的逻辑更改为Web服务方法，而不必重用代码

你有什么想法？同样，这是一个完全假设的场景，我们很多人过去都面临过，或者可能最终面临。

Answer 1

你错过了我要经历的第一步：

成本效益分析

重构应用程序是因为您觉得它感觉不舒服并不是一个好理由。它仍在运行（我在这一点上相当可靠地猜测）并且您的公司已经在代码中投入了大量时间和金钱。

您可能还有一个熟悉.NET 2.0和WebForms的开发人员团队，而许多人可能不了解您尝试引入的概念/代码。

在改变任何事情之前，先弄清楚投入了多少钱，你将在改变上花多少钱，以及将来会节省多少钱......

如果这些数字没有加起来，那么任何业务都不会让你继续。

Answer 2

1. 在撕毁之前，请确保您拥有一整套测试以涵盖现有代码。
2. 使用您的新技术编写新功能。
3. 如果由于功能请求需要修改旧代码，请将旧代码更新为新技术。
4. 只有在您感到无聊且无需编写新功能时，才能重构不需要更改的旧代码。

Answer 3

虽然它很诱人，但我个人不会对应用程序的体系结构进行这些重大更改，除非它们满足特定的用户要求。简单地实现这些以使应用程序在可维护性方面更好听起来像是一个很大的风险。通过将其中一个更改与遗留应用程序的其余部分集成，您可能会获得60％的成功并发现重大挑战。听起来你几乎要面对应用程序的完全重写，以确保一切都与新架构保持一致。您可能会花费大量时间进行重写，并发现可维护性只有一点点提高，以便重新占用重写时间需要很长时间。

如果它写得很糟糕或者像VB6这样的遗留语言，我个人会说这将是一个重大改写的候选人。但是，.NET 2.0是一种非常强大的语言，对于很多应用程序来说并没有瘫痪。根据您的描述，听起来应用程序设计得非常好。它实际上有一个数据访问层，业务对象，并以某种方式分层。考虑到您可以识别这些属性，这听起来是一个非常好的应用程序考虑一下自己的运气，这不是一些应用程序，它是如此混乱，你不能选择任何类似于特定设计模式的东西。

也许有些地方的东西有点讨厌，但有时候橡胶遇到道路并且东西连接在一起的地方并不漂亮。

Answer 4

我同意其他海报，除非你能证明节省成本，否则不要改写。

你可以做的是使用例如实体框架，MVC和jQuery编写系统的新区域，因为差异对于浏览器用户是透明的。随着时间的推移，您可以在进行升级/增强时逐步移动遗留代码。

在新系统代码上实现新技术也更容易，而不是移植现有代码。