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?
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
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.