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.
Related
I have a large rails application with 3 separate 'components'.
One is a mostly static WWW site, one is a shopping cart based on Spree, and one is a reward-program based on Instagram's API.
Currently they are all one giant Rails 4.0 application. As this app has grown over time, I have it harder to make distinctions between components. I want to modularize the app to keep these 3 components separate.
Is there a preferred way to do this "SOA" sort of architecture? or would it be better to turn each 'component' of the app into their own mountable engine? Or is there an even better strategy?
I have been looking at Spree's core, and how they have each component as an engine, and load them in the top level, and I'm thinking this may be the best route.
I don't have any experience with Ruby or Rails, but based on my experience you will need to ask/answer the below question and then decide how you want to proceed forward.
Who's going to be developing the code base and who'll be maintaining it?
If it's just you who's wearing all the hats, you may not want to have the overhead of implementing SOA (web-services to be specific). That said, you should definitely have a 'Contract' between each of these components or modules (however you refer to them). That way your modules/components can evolve independently and changes made to one to make the logic better doesn't necessarily mandate changes to the other components.
If it's you and a couple of other developers, I'd still say that you may not want to take the WS route yet.
If it's different teams that are developing and maintaining these components, then you are taking about an application at enterprise level and then you will start seeing the benefits of SOA (based on WS).
Cheers,
K
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
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.
If we will have to chose any one architecture pattern for web application in .Net, which one will be the best, MVC or 3 tier, How to decide ?
Jeevan,
I think you're unfortunately following a train of thought that many developers new to MVC take insofar as you've been 'fed' a belief that the 'M' in mvc (model) is purely a linq2sql flat implementation and that's it for the model. Not so... in our apps we have to cater for a mixture of web/desktop and handheld devices all using various areas of common functionality within them. we therefore have created a 'BLL/DAL' dll with all our business logic that is referenced as the 'M' in our mvc apps. This same 'bll/dal' is used in our webforms apps as well as in our desktop apps. in one current app, we're hooking into an oracle backend with our bll/dal dll and using MVC purely as a RESTful service acting as an intermediary between two legacy systems. given the design of our bll/dal dll, we could just as easily switch that to sqlserver, should (as and when) the business require.
so in a nutshell, the proposition of choosing MVC or 3 tier (and i actually think you are meaning layered, rather than tiered [which relates more to physical separation of functionality/services]) is totally a moot point as they are converging, rather than disparate technologies.
hope this helps - i'll try to source some examples via mr google later today to exemplify the fullness of my approach.
[edit] - from a similar question here on SO;
N-tier just refers to the physical structure of an implementation. These two are sometimes confused because an MVC design is often implemented using an N-tier architecture.
MVC Vs n-tier architecture
in a nutshell, one is object/API design, one is system architecture; both can live happily together.
Both are pretty high level concepts, and with all high level concepts there are no definitive answer. Moreover, you can quite succesfully mix them. For example have multitier application on the presentation tier, provide your application is large enough that this is required(for instance you had large cluster of data + analytics layer + reporting layer).
Everytime you're choosing between those 2, I would suggest thinking about these aspects:
What architecture you and your team feel most comfortable with in order to make a deadline
How complex your application really is and what will be specific benefits of using either of those architectures
What are usage pattern that your system will exercise, and which architectural solution fit address needs of these usage patterns better
How maintainable each solution will be
This list could go on of course, but I think these 4 things will get your on the right track.
From my experience architecture of more or less complex, real life system(that is not academic fantasy ones) is never MVC or 3 tier, but always is quite a mix of many things :)
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.