我们有一个在ColdFusion中构建的现有门户（基于Fusebox的自定义设计），并且正在寻求迁移到ASP.NET MVC。此门户网站具有模块，这些模块是真正独立的应用程序，可根据需要添加和删除。我们想开始使用ASP.NET MVC构建一个新的门户网站，但由于以下问题，我不确定这是如何工作的：
A）我们在当前ColdFusion门户中的数据库中所做的一切都是通过SQL存储过程完成的（许多基于选择的返回多个结果集）。我们的策略是在我们的应用程序中没有生成或特殊的SQL（一切都是通过存储过程完成的），我们希望保持这种方式。当我看到MVC时，模型似乎试图将所有内容抽象出来。
B）在我们当前的系统中，模块包含使用简单的cfinclude语句到模块/应用程序文件夹。他们也有自己的数据库（有时是单独的SQL服务器）;主门户核心运行所有相同的服务器和数据库集。这允许开发人员在不影响应用程序的任何其他部分（甚至可以访问它）的情况下处理特定的模块/应用程序。如果我们有一个MVC门户，开发人员如何处理其中的各个模块？
C）我们当前的门户使用单一登录，然后确定他们可以查看哪些模块/应用程序。如果我们想继续沿着这条路走，那是否需要我们在Visual Studio中有一个“项目”，它包含门户网站的主要部分和每个模块/应用程序？
我很感激有关如何开始的任何提示或提示，或者是否有人知道任何开源门户网站正在做类似的事情，我们可以从中获得一些基于门户网站的想法。
答案 0 :(得分：3)
布拉德，
我曾经问过一位老人在乡间小路上去某个地方的路线。他划了一下他的下巴，然后庄严地回答，＆＃34;你不能从这里到达那里。＆＃34;我担心你可能在同一条船上。如果你想密切关注MVC 和让代码分离和的单个模块保持数据访问层的灵活性而不抽象 - 你可能会拔掉你的头发。保险箱，虽然老了或多或少＆＃34;程序＆＃34;尽管它似乎正在为你规定这些规则。 Fusebox本身就是一种发展模式，你的习惯也符合它。 .NET MVC（或者通常只是MVC）是一种完全不同的模式，因此需要遵循不同的规则。上面的具体内容我会说：
A）没有理由你不能继续使用你的存储过程并仍然保持MVC - 它需要比你想要的更多的自定义编程 - 但你的DAO层并不关心什么＆＃39;在另一方面开发数据。它的工作是返回数据集和结果等。但它看起来不像ORM或其他任何东西 - 它需要在对象中自定义调用DB。
B）我不认为这是可行的。
C）同样 - 我认为转移到MVC会将此作为一个选项排除在外，除非你想在文件级别专门启用dev访问 - 这对我来说听起来像是灾难的秘诀。
如果您在转换过程中需要帮助维护CF FB应用程序，或者如果您需要帮助进行此迁移，请告诉我们。我们的团队做了大量的这类工作。
标记