Reputation: 2335
Currently there are multiple (about 15-30) independent web applications written in another language. Each one is completely independent with files, images, headers, users, databases etc. etc. The whole 9yards, except that they all exist under the same domain and should have the same style (but they don't). They will soon be converted to C# ASP.NET MVC 2. They do share the same LDAP authentication.
The question has come up in my mind as to whether these should be setup as multiple MVC solutions or be done within a single MVC application. They will all have the same styles, mostly the same images, and it would be nice for them to share basic functions.
The reason this isn't a simple cut and dry solution to me, is that some of these applications are quite large by themselves and throwing them all together might be hard to manage. Not to mention the development of new applications will continue as well as new features added to the existing ones. Making this possibly an extremely large solution.
I am fairly new to MVC and even though I have a good understanding of it now, I'm still trying to rewire my brain here and there to work with the methodology and design.
I guess what I'm asking for, is those of you who have more experience with MVC than I do to share some incite and wisdom about MVC in practical use to give me a direction to start thinking.
Upvotes: 3
Views: 381
Reputation: 21355
Please, make yourself a favor and do not combine them in a single solution. I worked once in a project where we had one huge solution to work and that was the root of all evil. If you place everything in a single solution, you are increasing the complexity of all projects, you might be thinking, I am actually going to save a few lines of code by reusing something, but the truth is that you are creating a deadly solution which will become a bottleneck eventually
Consider the following:
The performance of Visual Studio is affected when you have more than 30-40 projects, which means that your build is going to take more and more time.
If you implement a build server (and you should) if you have one huge solution, the script to build only the projects related to each application would be really complex
Now I think you already did the most difficult part of the design when you say:
Currently there are multiple (about 15-30) independent web applications written in another language
If your applications are independent that means they have an independent domain, so there is no reason to place them in a single solution, not even treat them as modules.
Managing independent solutions does not mean that you cannot have shared components among them, (BTW when I say shared components I mean infrastructure components, please do not try to reuse domain objects).
So now the question is how should I reference the shared components?
In these days, I have found that the best way to reuse infrastructure components among solutions-projects, is by using Nugets. Using Nugets makes it easy to distribute new version of the components, so my suggestion is: create a private Nuget server in your organization (a simple IIS application) and add to this server your own private packages and just reference them from your solutions
You can place in your Nuget packages practically anything you need including:
This is a good article to create a private Nuget repository
To create a Nuget:
And finally to integrate the creation of a Nuget in your CI server:
Upvotes: 3
Reputation: 3490
I totally agree with Marks answer, ask yourself "why" do you need to combine them. Do they really need to be independent?
My additional comments though are....
What you should definitely think of....
Create a unified CSS files which use the same images to be used by your applications
Write some universal JQuery (Mobile version if these are public facing) using JQuery templates/partial views as well to give all these seperate applications a unified experience
If you are not going to unify your server side code in terms of the DAL etc, then just concentrate on the client side.
Upvotes: 1
Reputation: 3540
The same style could be accomplished with a unified stylesheet referenced by all, as long as you use similar mark-up in your pages within the apps. Common functionality could be provided through a unified class library. To me, it really depends on exactly how close the style and functionality are between apps... do you want the exact same markup on every page, etc.
Upvotes: 2
Reputation: 5585
It is common to have an instance of the Controller per application, however if you implement this using a data driven Front Controller then there only needs to be a single Class within your new WeB Application framework. So each Application might have a configuration file that maps URL to Command Class files. These can be constructed on demand or requested from a Resource Pool. A big advantage of this approach is that many of these commands would start as a very thin wrappers (ServiceToWorker) over the existing application and/or ASP views.
Upvotes: 1
Reputation: 32758
When I go for combining multiple web applications into single.. I'll consider the below points.
In your case you said each one of them is completely independent then why you need to combine?
Upvotes: 3
Reputation: 1620
My recomendation is DI and create each proyect like a plug-in ,so each proyect can be developed or manage in separate without affect others
I have a few proyects with MEF and it's so easy create new or manage existents plug-ins
Here is a getting started MVC and MEF… http://blog.maartenballiauw.be/post/2009/04/21/ASPNET-MVC-and-the-Managed-Extensibility-Framework-%28MEF%29.aspx
and a downloadable example http://www.hanselman.com/blog/ExtendingNerdDinnerAddingMEFAndPluginsToASPNETMVC.aspx
Upvotes: 2