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

Question

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

• Web表单
• 数据层是各地的SqlCommand瘦包装调用存储过程
• 简陋的DTO其经由存储过程填充充当网络表单和数据库之间的网关
• A“业务逻辑”层式的业务对象（即后面的代码调用层）

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

IMO的变化将涉及：

• 介绍像的LINQ的ORM to SQL和摆脱存储过程的CRUD的
• 假设你不能只是抛出Web表单，介绍了MVP模式表格
• 确保网关类符合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编写系统的新区域，因为这些差异对于浏览器用户来说是透明的。在升级/增强功能时，您可以随时移动旧代码。

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