将ASP.NET 2.0应用程序重构为更“现代”[关闭]

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

成本效益分析

重构一个应用程序,因为你觉得它老了不是一个好理由。它仍在运行(我猜这一点相当可靠),而且您的公司已经在代码上投入了大量的时间和金钱。

您可能还拥有一个熟悉.NET2.0和Webforms的开发团队,而许多开发人员可能不理解您试图引入的概念/代码。

在改变任何事情之前,先弄清楚你投资了多少钱,你将在你的改变上花费多少钱,以及它将在未来节省多少钱……

如果数字加不起来,就没有生意能让你继续下去。

1. 在分解现有代码之前,请确保有一套完整的测试来覆盖它。
2. 使用新技术编写新功能。
3. 如果由于功能请求而需要修改,请将旧代码更新为新技术。
4. 重构不需要更改的旧代码,前提是您感到无聊并且没有新的功能要编写。

虽然这很诱人,但我个人不会对应用程序的体系结构进行这些重大更改,除非它们满足特定的用户需求。简单地实现这些以使应用程序在可维护性方面更好听起来是一个很大的风险。您可能会有60%的成功率,并且在将这些更改之一与遗留应用程序的其余部分集成时会遇到重大挑战。听起来你几乎要面对对应用程序的完全重写,以确保所有内容都与新的体系结构一致。您可能会在重写中投入大量时间,并且发现可维护性只提高了一点点,因此重新获得在重写中投入的时间将需要很长时间。

如果它写得很差,或者是用vb6这样的传统语言,我个人会说它是一个重大重写的候选人。然而,.net 2.0是一种非常有能力的语言,对于许多应用程序来说,它并没有被破坏。从你的描述来看,这个应用程序看起来设计得很好。它实际上有一个数据访问层,业务对象,并且以某种方式分层。考虑到您可以识别这些属性,这听起来是一个非常好的应用程序。想想你自己吧,幸运的是,这不是一个应用程序,它是如此混乱,你不能挑出任何类似于一个特定的设计模式。

也许有些地方的情况有点糟糕,但有时不是很好的地方,橡胶遇到了道路和东西连接在一起。

我同意其他海报,不要重写,除非你能证明节省成本的好处。

您可以做的是使用eg entity framework、mvc和jquery编写系统的新区域,因为这种差异对浏览器用户是透明的。随着时间的推移,您可以在进行升级/增强时一点一点地移动遗留代码。

在新的系统代码上实现新技术总是比移植现有代码更容易。