关于新项目的建议:现有ASP.NET应用程序的附加功能
本文关键字：应用程序 NET ASP 功能 新项目 现有 | 更新日期: 2023-09-27 18:28:05
正在寻找有关我即将参与的项目的建议，该项目围绕着向运行在VB.NET中编程的IIS 6.0上的现有ASP.NET应用程序添加某些功能展开。
为了帮助未来的开发，客户希望附加功能尽可能经得起未来的考验。理想情况下，我已经说过，我想推动一个使用ASP.NET MVC3的解决方案，运行IIs 7.5和.NET 4，用C#编写。该解决方案将作为当前门户网站的无缝添加，可能只是一个额外的选项卡页面。
但它们将是完全独立的网络应用程序。这是至关重要的。
我可以预见的主要问题首先是在asp.net网络应用程序和新应用程序之间共享会话细节。特别是在维护会话状态方面（以及不让IIS在其中一个应用程序上超时）。此外，在我的脑海中，将这两个"应用程序"结合在一起似乎有问题，尽管这可能比我担心的要简单得多。
我正在为这两个问题征求建议，如果有人有任何想法，请说！
到目前为止，我已经提出了以下解决方案，无论它们是否糟糕：
1） 将新功能嵌入到现有的代码库中（不是一个好的选择）。这将意味着失去任何潜在的未来升级能力，也意味着没有通过使用MVC框架来遵循更好的OO约定。
2） 使用iFrame链接到一个单独的MVC3应用程序（我目前喜欢的一个）的剃刀页面。允许使用所有新技术，但缺点是共享会话数据。要么通过iFrame"属性"（这可能吗？），要么通过将会话状态持久化到数据库？（慢？）甚至应用程序之间的某种web服务交互来推送/拉取用户/会话数据？
非常感谢您的任何建议！
我同意你的观点，C#和MVC是"前进的道路"，但不幸的是，将两个应用程序混合在一起会让你头疼，尤其是不同的会话ID。你可能需要一个共享的数据库表来将它们映射在一起，正如你可能已经想象到的那样，这散发着"创可贴"的味道。
在C#中重建现有内容的后果是什么？也许你可以建议完全升级。客户自己似乎也在赞美经得起未来考验的优点，因此这将是一条路。不，我不会提倡使用"代码转换器"，但它真的不应该那么难。
我想，接下来要考虑的是"经得起未来考验"。客户端是否担心VB.NET会很快消失，或者将来无法处理任何事情？老实说，我觉得这是一个非常不可能的情况。
我想我有点含糊其辞，但从本质上讲，将两个应用程序（一个具有旧功能，另一个具有新功能）结合在一起会让人头疼。这可以通过将旧站点迁移到C#/MVC，然后添加额外的功能来解决。诚然，这在今天看来可能是一个巨大的承诺，但在未来，它将带来回报。
如果当前站点可以升级到.NET 4.0，那么就没有理由不扩展现有的应用程序。
没有什么可以阻止你混合MVC和web表单（事实上，有几篇关于如何做到这一点的文章）。没有什么可以阻止你混合使用VB.NET和C#（或者，据我所知，阻止你在VB.NET中使用MVC）
你必须非常努力地让我相信使用iFrame的优点。很难。你可能会说服我同时运行两个应用程序的优点——功能按文件夹划分——但老实说，我会更乐意升级现有网站，然后从那里构建。