目前我正在使用一个庞大，陈旧且编写得非常糟糕的ASP.NET 1.1应用程序，并且持续维护正成为一个相当大的问题。基本上它正在达到突破点，我不愿意扩展它，而不仅仅是业务所要求的扩展。根据我从头开始创建其他项目的经验，它非常适合基于ASP.NET MVC的解决方案。哦，我多么希望世界如此简单......
事实是，我无法证明从头开始重写它并且企业负担不起。理想的解决方案是开始编写基于MVC的应用程序，并在新需求出现时开始缓慢迁移。
我看过帖子说这完全有可能，但在我的实验中，我发现它并不那么容易。当前应用程序包含由公司生成的其他应用程序共享的多个大型数据访问和业务逻辑层。这些也是用1.1编写的，不会在2.0中编译（如果我试过的话会破坏其他项目！）所以我无法升级它们。由于我无法做到这一点，我坚持使用甚至无法在支持.NET 3.5的可视化工作室中打开的应用程序。新的MVC应用程序也必须使用这些层。
我完全乐于接受建议。我迫切希望找到一个解决方案，我可以迅速证明这个解决方案可以让我在不花太多时间或影响其他业务的情况下极大地改进产品。
答案 0 :(得分：2)
您可以在现有业务层之上编写WCF服务，让新应用与该服务通信，而不是直接引用业务层。
答案 1 :(得分：0)
你需要分而治之。分析当前的应用程序及其图层，看看是否找到了将每个重要功能划分为离散区域的方法，尽可能少地进行更改。 然后使用旧技术使每个区域成为独特的服务。 然后你可以慢慢地重写每个服务，因为你可以适应它而不影响整个服务。
否则，您将不得不为您的经理提出令人信服的商业案例，以便他们为您分配正确的工作时间。有时候我们的工作既是政治性的，也是技术性的。