ASP.NET MVC中的多个应用程序门户(从ColdFusion迁移)

Question

我们有一个在ColdFusion (定制的基于Fusebox的设计)中构建的现有门户，并希望迁移到ASP.NET MVC。该门户有真正独立的应用程序模块，可以根据需要添加和删除这些应用程序。我们希望开始使用ASP.NET MVC构建一个新的门户，但由于以下考虑，我不确定它将如何工作：

A)我们在当前ColdFusion门户中在数据库中所做的一切都是通过SQL存储过程完成的(许多基于select的存储过程返回多个结果集)。我们的策略是，我们的应用程序中没有生成或临时SQL (一切都是通过存储过程完成的)，我们希望保持这种状态。当我看MVC时，这个模型似乎试图抽象出所有的东西。

( B)在我们当前的系统中，使用简单的cfinclude语句将模块包括到模块/应用程序文件夹中。它们也有自己的数据库(有时也有单独的SQL服务器)；主门户核心运行在同一服务器和数据库集中。这允许开发人员在不影响应用程序的任何其他部分(甚至可以访问它)的情况下处理特定的模块/应用程序。如果我们有一个MVC门户，那么开发人员如何在其中的各个模块上工作呢？

( C)我们当前的门户使用一个登录名，然后确定他们可以查看哪些模块/应用程序。如果我们想继续沿着这条路走下去，这是否需要在Visual中有一个包含门户和每个模块/应用程序的主要部分的“项目”？

我很感激关于如何开始的任何提示或提示，或者如果有人知道有任何开源门户正在做类似的事情，我们可以从中获得一些想法来建立我们的门户。

Answer 1

布拉德

有一次，我问一位老人如何去乡村公路上的某个地方。他挠了一下下巴，然后郑重地回答说：“你不能从这里到那里。”恐怕你们可能在同一条船上。如果您希望更接近MVC，并且有单独的代码分离模块，并且保持您的数据访问层的灵活性，而不需要抽象，那么您可能会拔掉您的头发。Fusebox，虽然年事已高，或多或少是“程序性的”，尽管它看上去是在为你规定这些规则。熔断器本身就是一种发展模式，你的习惯也符合它。MVC (或者只是MVC )是一种完全不同的模式，因此需要您遵循不同的规则。

特别是在上述项目中，我要说：

( A)您没有理由不能继续使用您存储的过程，并且仍然保持MVC --它将需要比您想要的更多的自定义编程--但是您的DAO层并不关心在另一边开发什么数据。它的工作是返回数据集和结果等，但它看起来不像ORM或其他什么-它将需要自定义调用在您的对象中的DB。

我不认为这是可行的。

( C)再次--我认为迁移到MVC将排除将其作为一种选择，除非您希望在文件级别上具体启用dev访问--这听起来会给我带来灾难。

如果您在过渡期间需要帮助维护CF应用程序，或者需要帮助进行此迁移，请告诉我。我们的团队做了很多这样的工作。

标记