ASP.NET MVC 中的多个应用程序门户（从 ColdFusion 迁移）
Multiple application portal in ASP.NET MVC (migrating from ColdFusion)
我们有一个内置于 ColdFusion 中的现有门户（基于自定义 Fusebox 的设计），并希望迁移到 ASP.NET MVC。这个门户网站有一些模块，它们是真正独立的应用程序，可以根据需要添加和删除。我们想开始使用 ASP.NET MVC 构建一个新门户，但由于以下问题，我不确定这将如何工作：
A) 我们在当前 ColdFusion 门户中的数据库中所做的一切都是通过 SQL 存储过程完成的（许多基于 select 的存储过程返回多个结果集）。我们的政策是我们的应用程序中没有生成的或临时的 SQL（一切都通过存储过程完成），我们希望保持这种状态。当我查看 MVC 时，该模型似乎试图将所有内容抽象出来。
B) 在我们当前的系统中，使用简单的 cfinclude 语句将模块包含到 module/application 文件夹中。他们有自己的数据库（有时还有独立的 SQL 服务器）；主要门户核心通过同一台服务器和一组数据库运行。这允许开发人员在特定 module/application 上工作，而不会影响应用程序的任何其他部分（甚至无法访问它）。如果我们有一个 MVC 门户，开发人员如何在其中处理各个模块？
C) 我们当前的门户使用单一登录，然后确定 modules/applications 他们可以查看的内容。如果我们想继续沿着这条路走下去，是否需要我们在 Visual Studio 中有一个包含门户主要部分和每个 module/application 的 'project'？
我将不胜感激关于如何开始的任何提示或提示，或者如果有人知道任何开源门户网站正在做类似的事情，我们可以从中获得一些想法来构建我们的门户网站。
布拉德，
我曾经在乡间小路上向一位老人问路。他挠了挠下巴，然后郑重地回答说，"You can't get there from here." 恐怕你也是同病相怜。如果您希望与 MVC 密切相关 and 具有代码分离的单独模块 and 保留数据访问层的灵活性而无需抽象 - 您可能是会拔掉你的头发。 Fusebox，尽管看起来很老，但或多或少 "procedural" 正在为您制定这些规则。 Fusebox本身就是一种养成模式，你的习惯已经符合了。 .NET MVC（或一般的 MVC）是一种完全不同的模式，因此需要您遵守不同的规则。
在以上各项中，我特别要说的是：
A) 没有理由你不能继续使用你的存储过程并仍然保持 MVC - 它需要比你想要的更多的自定义编程 - 但你的 DAO 层不关心另一端正在开发什么数据.它的工作是返回数据集和结果等。但它看起来不像 ORM 或其他任何东西 - 它需要对对象中的数据库进行自定义调用。
B) 我觉得不可行
C) 再次 - 我认为转向 MVC 将排除此选项，除非你想在 文件级别 专门启用开发访问 - 这听起来像是灾难的秘诀对我来说。
如果您在转换期间需要帮助维护 CF FB 应用程序，或者如果您需要帮助进行此迁移，请告诉我。我们的团队做了大量此类工作。
马克
我们有一个内置于 ColdFusion 中的现有门户（基于自定义 Fusebox 的设计），并希望迁移到 ASP.NET MVC。这个门户网站有一些模块，它们是真正独立的应用程序，可以根据需要添加和删除。我们想开始使用 ASP.NET MVC 构建一个新门户，但由于以下问题，我不确定这将如何工作：
A) 我们在当前 ColdFusion 门户中的数据库中所做的一切都是通过 SQL 存储过程完成的（许多基于 select 的存储过程返回多个结果集）。我们的政策是我们的应用程序中没有生成的或临时的 SQL（一切都通过存储过程完成），我们希望保持这种状态。当我查看 MVC 时，该模型似乎试图将所有内容抽象出来。
B) 在我们当前的系统中，使用简单的 cfinclude 语句将模块包含到 module/application 文件夹中。他们有自己的数据库（有时还有独立的 SQL 服务器）；主要门户核心通过同一台服务器和一组数据库运行。这允许开发人员在特定 module/application 上工作，而不会影响应用程序的任何其他部分（甚至无法访问它）。如果我们有一个 MVC 门户，开发人员如何在其中处理各个模块？
C) 我们当前的门户使用单一登录，然后确定 modules/applications 他们可以查看的内容。如果我们想继续沿着这条路走下去，是否需要我们在 Visual Studio 中有一个包含门户主要部分和每个 module/application 的 'project'？
我将不胜感激关于如何开始的任何提示或提示，或者如果有人知道任何开源门户网站正在做类似的事情，我们可以从中获得一些想法来构建我们的门户网站。
布拉德，
我曾经在乡间小路上向一位老人问路。他挠了挠下巴，然后郑重地回答说，"You can't get there from here." 恐怕你也是同病相怜。如果您希望与 MVC 密切相关 and 具有代码分离的单独模块 and 保留数据访问层的灵活性而无需抽象 - 您可能是会拔掉你的头发。 Fusebox，尽管看起来很老，但或多或少 "procedural" 正在为您制定这些规则。 Fusebox本身就是一种养成模式，你的习惯已经符合了。 .NET MVC（或一般的 MVC）是一种完全不同的模式，因此需要您遵守不同的规则。
在以上各项中，我特别要说的是：
A) 没有理由你不能继续使用你的存储过程并仍然保持 MVC - 它需要比你想要的更多的自定义编程 - 但你的 DAO 层不关心另一端正在开发什么数据.它的工作是返回数据集和结果等。但它看起来不像 ORM 或其他任何东西 - 它需要对对象中的数据库进行自定义调用。
B) 我觉得不可行
C) 再次 - 我认为转向 MVC 将排除此选项，除非你想在 文件级别 专门启用开发访问 - 这听起来像是灾难的秘诀对我来说。
如果您在转换期间需要帮助维护 CF FB 应用程序，或者如果您需要帮助进行此迁移，请告诉我。我们的团队做了大量此类工作。
马克