多个应用程序门户

我们已经建立了ColdFusion的（基于定制的保险丝盒设计）和现有的门户正在寻找移动到ASP.NET MVC。该门户网站具有真正独立的应用程序模块，可根据需要添加和删除这些应用程序。我们希望开始使用ASP.NET MVC构建一个新门户，但我不确定这将如何工作，因为以下几点：多个应用程序门户

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

B）在我们目前的系统中，模块使用简单cfinclude语句到模块/应用程序文件夹包括在内。他们有自己的数据库（有时也包括单独的SQL服务器）;主要的门户内核都通过同一台服务器和一组数据库运行。这允许开发人员在不影响应用程序的任何其他部分（甚至无法访问它）的情况下处理特定的模块/应用程序。如果我们有一个MVC门户，开发人员如何处理其中的各个模块？

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

我将不胜感激如何开始任何提示或暗示，或者任何人，都在做类似的，我们可以得到从立足我们的门户网站的一些想法任何东西开源门户知道。

来源

2015-01-08 Brad

Port？不...你可以更好地使用它作为模型，并从头开始重写.NET，并使用C＃和Razor MVC 5 thingy。 –

我们绝对不想移植。除了可能的一些存储过程之外，这是对所有内容的重写。 – Brad

（投票结束，因为它不是那种可以在网站的几段中明智地回答的事情，你可能需要得到一些人来评估需要做什么）。 –

布拉德，

我曾经问过一个老人的方向到乡村道路上的某个地方。他挠了挠下巴一会儿，然后庄严地回答：“你不能从这里到达那里。”我担心你可能会坐在同一条船上。如果要密切色调MVC 和有单独的模块，代码分离和保留您的数据访问层的抽象没有的灵活性 - 你可能要拿出你的头发。尽管看起来像是为你规定了这些规则，但保险箱虽然老化并且或多或少是“程序性”的。保险丝盒本身就是一种发展模式，你的习惯已经符合它。 .NET MVC（或者一般的MVC）是一种完全不同的模式，因此需要遵守不同的规则。

的项目中上述具体我要说的是：

A）没有理由不能继续使用存储的特效，但仍保持MVC - 这将需要更多的定制编程比你想 - 但你的DAO层不关心在另一端开发数据的是什么。它的工作就是返回数据集和结果等，但它看起来不像ORM或其他什么 - 它需要在对象中对数据库进行自定义调用。

B）我不认为这是可行的。这听起来像一个灾难，我 -

C）再次 - 除非你想明确地使在文件级 dev的访问我想移动到MVC会排除这个作为一个选项。

让我知道如果你需要帮助维持CF FB应用，而要转换，或者如果你需要帮助，使这个迁移。我们的团队做了很多这类工作。

马克

来源

2015-01-08 16:54:50

谢谢马克。这绝对看起来将是一个重大挑战。放弃使用MVC设计的想法是什么？这是否会以任何重大方式改变任何答案，或者更多的是从ColdFusion转移到.NET时完全代码设计和结构的转变。 – Brad

当然可以 - 如果您选择创建一个模仿FB模式的框架，那么您可以非常轻松地遵循现有的SDLC。几年前甚至有一个.NET FB框架 - 尽管很多版本以前。谨慎（正如你可能已经知道的那样），你会创建一个_non MVC_模式，并且可能以非“.NET”方式进行操作。所以它会保持你的SDLC不被破坏，但它可能不是一种改进。 –

多个应用程序门户

回答

相关问题