tags:

views:

35

answers:

2

Hello,

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

+1  A: 

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.

jfar
+1  A: 

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.

Stephen M. Redd
@Stephen M. Redd: Well! I couldn't expect better. Honestly, I've using class library for the wrong reasons. That's why, I'm running into circular referencies issues all the time. From my actual understanding, I should go with Areas. Anyway, it might time when I'll need a central pieces of functionnality, then I'll write class library. Thanks a lot.
Richard77
I'm really glad that I've asked this question and also had the opportunity to get such a nice, instructing answer.
Richard77
No problem Richard. You aren't alone... a LOT of projects run into that problem. My rule of thumb is this: if I don't KNOW for sure that I will use the code in another application, I don't split it out into separate class libs. If you are careful in how you use namespaces and folders, and are good at avoiding tight-coupling between classes, then it is absolutely trivial to split your code into class libs later on. The exception to this rule though is that I NEVER put business code directly in the web project itself. Keep the web project pure presentation.
Stephen M. Redd
BTW, a similar principal applies to OO techniques in general too. If you have a base class or interface that is only ever inherited by one single class in your application, then you should consider if you are over-designing. Unit testing and dependency injection in particular often pushes people into horribly complex inheritance situations. If you can't identify what the complexity does to make the core application better, then that complexity is probably not helping your design.
Stephen M. Redd
if you don't put the business code directly in the web project, where do you put?
Richard77
A class library for the business/data access is the way to go, but usually just one is enough. The biggest reason not to put biz code in the web app is to avoid tightly coupling the biz code to asp.net objects like HttpContext or HttpRequest. In a class lib that doesn't reference System.Web, you aren't tempted to do that. When coupling with asp.net objects really is needed or convenient, extension methods in the web app can extend the classes from the biz library. So it isn't quite true that zero biz code is in the web app... but none of the critical biz logic should be in the web app.
Stephen M. Redd
If you want more detail, send me a message at: http://reddnet.net/contact.aspx
Stephen M. Redd
"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." This statement requires more nuance. An MVC app can easily be split up into different sections without Area support. Areas just provide a layer of abstraction away from configuring all of that information yourself. Areas don't provide any "splitting" that you can't do yourself.
jfar
@ I really thank you all
Richard77