Can you please tell me advantages/drawbacks of these two implementations?
My context : We have a large project which includes many differents domains. Each domain will naturally be an Area. But many differents teams will work on each and we want to separate business rules. What is the best way to manage these ares in a solution ?
I have seen many examples of Areas in separate project or with portable areas.
But i can not take decision.
From my point of view :
Separate Project
Simple
Difficult to manage Content (JS, CSS, ...). Does it must be in the main site ?
Best performances
Portable Areas
All content, views must be in the same project
Possible code duplicate between areas
Contraints : name , embedded ressources, ...
Part of MVC Contrib : will it me supported longer ?
Component : ideal for redistribute a feature
Thanks,
I'm facing the same problem, and have been checking for it.
The following link is something about portable areas. The first answer is given by the lead of MS MVC development team. Although it can not answer the question, wish it can help you a litle.
Multiproject areas in ASP.Net MVC 3
Related
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.
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:
Assemblies
XML config files (including common XML logger configuration files)
Common JavaScript files
Common Style Sheets files
etc...
This is a good article to create a private Nuget repository
http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds
To create a Nuget:
http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package
And finally to integrate the creation of a Nuget in your CI server:
http://www.hanselman.com/blog/NuGetForTheEnterpriseNuGetInAContinuousIntegrationAutomatedBuildSystem.aspx
http://docs.nuget.org/docs/reference/command-line-reference
When I go for combining multiple web applications into single.. I'll consider the below points.
If all the applications shares a common business model.
If they shares a common infrastructure (security, validation, logging and others..)
If they shares same a common user base.
If combining multiple projects into one helps me to reduce the cost of maintenance and enhancement.
In your case you said each one of them is completely independent then why you need to combine?
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
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.
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.
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.
To make a projet manageable, we break it into sub-projets (class libraries in C#, for instance). Now, in ASP.NET MVC 2, we do have Areas. I'd like to know if Areas have or can serve the same purposes as class libraries? It looks like both are meant to make a project manageable...
Personaly, I'm about to write something bigger. I don't know which way to go: Area vs class library...both?
Thanks for helping
Making a project manageable is really not the point of areas nor class libraries, though they do have that effect when used well.
Generally, the purpose of a class library is more about creating a stand-alone library of code that all serves some inter-related purpose. The point is really that a well used class library represents a collection of code that is maintained, developed, and distributed as a single unit. The big key is the distribution though, since class libraries can be distributed and used in many applications. It is usually a waste of time to split code out into class libraries if those libraries are never distributed, maintained, or developed independently. If they exist just to organize and group code that is otherwise dependent on other code in other libraries then you may be making your code less manageable in the long run; namespaces and folders alone can serve the purpose of keeping code grouped, organized, and manageable.
Areas in MVC are a tad different. Their purpose is to partition large web applications into semi-independent segments that are all hosted in a single project (and thus are part of the same class library; an MVC app is just a fancy kind of class library). So the entire purpose of areas tends to be responsibility. The biggest advantage of areas is that they are useful to split large applications into sections that are maintained and developed by separate teams of developers; or into sections that have widely different infrastructure requirements from other sections of the application.
So in terms of manageability alone, areas are a good idea if your MVC app is large and has distinct functional sections. Class libraries can only be justified if there are other benefits aside from code manageability.
At the most basic level your comparing how C# is compiled into a specific framework feature.
Areas are simply built in routing/finding/searching customizations against so you can separate your app into different folders. You could provide your MVC application with a VirtualPathProvider and use views embedded in class libraries to segment your application but it isn't the standard way of organizing things.
I'm starting a new web application that will be made of multiple parts or modules.
My client want to be able to redistribute the application with a subset of modules to some other clients. I read about Areas in mvc2 which seems to be what i'm looking at.
I would also like to develop those modules in side projects and have the right one build according to clients specifications.
Can someone with more experience than me with mvc can confirm that this is possible with areas.
thanks
mateo
You actually don't need areas for this. If you develop each module in a separate project within a solution they will each have their own assembly. This should work unless I'm misunderstanding your requirements.
To further clarify: areas are generally used to separate a very large application into sections that may each have a different development team. For example stack overflow might have the question + answer engine area, the roles and permissions area, login and authentication, and so on.
I think each module should be a separate project (a single assembly/DLL with its own responsibilities). You'd "connect" each module as a lego :D. Then to redistribute the app with a subset of modules you'd have a build script where you specify the modules that are in and out of the final product. Each version of the product would come in different shapes (as in the lego game) presenting different functionality subsets.
Just to mention, the concept of Areas in MVC is this:
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).
For example, a single large e-commerce
application might be divided into
areas that represent the storefront,
product reviews, user account
administration, and the purchasing
system. Each area represents a
separate function of the overall
application.
The app I'm working on is large enough to break up into areas, but before I do so, I was hoping to get a better idea of when to implement areas in a single project versus multiple projects.
This article only mentions team size as a factor for choosing, but that doesn't really make sense to me
http://msdn.microsoft.com/en-us/library/ee461421(VS.100).aspx
Recommend that you use single-project areas, as we've made considerable strides in its support and stability. The multi-project areas code is very fragile, and there is a higher-than-zero likelihood that it will be removed or pushed to Futures in the near future.
It would kind of be like S[OFU] except there will be more differences between the site.
What are good ways to develop 3 site at once with a different look and different functionality? I believe with the look i may only change the CSS and some backend data for different categories. I also need some functionality and options to be specific to one or two but not all sites.
Whats the easiest way to develop, maintain and test the sites during the development process? I am hoping something simple like changing the root directory in the visual studio IDE can be enough and have site specific features enabled through config files in the site specific root directory.
You might want to consider developing in a somewhat modular manner. That way, common elements can be shared between the sites completely (just 2 deployments of the same code), while elements that vary are their own independent modules.