我想到的问题是,这些是应该设置为多个MVC解决方案还是在单个MVC应用程序中完成.它们都具有相同的样式,大多数是相同的图像,并且它们分享基本功能会很好.
这对我来说不是一个简单的切割和干燥解决方案的原因是,这些应用程序中的一些本身非常大并且将它们全部放在一起可能很难管理.更不用说新应用程序的开发将继续,并且新功能将添加到现有应用程序中.使这可能是一个非常大的解决方案.
我对MVC很新,尽管我现在已经对它有了很好的理解,但我仍然试图在这里和那里重新连接我的大脑来处理方法和设计.
我想我要求的是,那些对MVC有更多经验的人比我在实际使用中分享一些关于MVC的煽动和智慧给我一个开始思考的方向.
请帮个忙,不要将它们组合在一个解决方案中.我曾经在一个项目中工作过一次,我们有一个巨大的工作解决方案,这是万恶之源.如果你把所有东西放在一个解决方案中,你可能会增加所有项目的复杂性,你可能会想,我实际上是通过重用一些代码来保存几行代码,但事实是你正在创建一个致命的解决方案,最终会成为瓶颈考虑以下：
>当您有超过30-40个项目时,Visual Studio的性能会受到影响,这意味着您的构建将花费越来越多的时间.
>如果您实现构建服务器(并且您应该),如果您有一个巨大的解决方案,那么仅构建与每个应用程序相关的项目的脚本将非常复杂
现在我认为你已经完成了设计中最困难的部分,当你说：
Currently there are multiple (about 15-30) independent web applications written in another language
如果您的应用程序是独立的,这意味着它们具有独立的域,那么没有理由将它们放在单个解决方案中,甚至不将它们视为模块.
管理独立解决方案并不意味着您不能在它们之间共享组件,(当我说共享组件时,我指的是基础架构组件,请不要尝试重用域对象).
所以现在的问题是我应该如何引用共享组件？
在这些日子里,我发现在解决方案项目中重用基础架构组件的最佳方法是使用Nugets.使用Nugets可以轻松分发新版本的组件,因此我的建议是：在您的组织中创建一个私有Nuget服务器(一个简单的IIS应用程序),并将自己的私有软件包添加到此服务器,并从您的解决方案中引用它们
您可以在Nuget包中放置几乎所有需要的东西,包括：
>装配
> XML配置文件(包括常见的XML记录器配置文件)
>常见的JavaScript文件
>常用样式表文件
>等……
这是一篇创建私有Nuget存储库的好文章
> http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds
要创建Nuget：
> http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package
最后,在您的CI服务器中集成Nuget的创建：
> http://www.hanselman.com/blog/NuGetForTheEnterpriseNuGetInAContinuousIntegrationAutomatedBuildSystem.aspx
> http://docs.nuget.org/docs/reference/command-line-reference