We have a large MVC .NET website for a hospital; it has a Doctor Portal, and a Patient Portal. In essence it is two sites, with very little feature overlap. We outsourced the Doctor part to a Vendor and now we are creating the Patient part. I am recommending that we create two separate MVC projects since we are creating the Patient portal from scratch and don’t want the headache of integrating within the other code. Control, Route clashes etc. There are already 100 routes in the Global.asax for the doctor site. The Director is somewhat technical and wants me to explain why I want to create another project. I simply don’t want the headache of having to work in other code, within the same view folder, and control folder. What are my options? Am I jumping the gun, and should just stick to the current project. Also the doctor site is live and we are adding the patient part. Does MVC/.NET offer a workaround for this?
One of the benefits you'd get by using two different projects is that if one part of your system falls, the other doesn't. If everything is chained together you might bring the whole thing down.
If they're on separate projects (separate servers,etc.) then your patient portal would survive; and as you say, the patient portal shares very little with the Doctor portal.
This sounds like a good case for using MVC Areas - a feature added in MVC 2. Check out this MSDN article for more information.
From the article itself:
... However, some applications can have a large number of controllers, and each controller can be associated with several views. For these types of applications, the default ASP.NET MVC project structure can become unwieldy.
To accommodate large projects, ASP.NET MVC lets you partition Web applications into smaller units that are referred to as areas. Areas provide a way to separate a large MVC Web application into smaller functional groupings. An area is effectively an MVC structure inside an application. An application could contain several MVC structures (areas).