MVC Areas for enterprise - good or bad? [closed]

Question

Within a single project solution introducing Areas when you have a lot of controllers does improve separation and allows modules to easily be copied in or out of the solution. However in a large enterprise solution I would favour splitting the logic into separate projects instead.

Thus having separate UI, Controller, SOA, Model and Repository projects. In this scenario Areas don't make sense any more, plus they add an extra top level to the Url which is often not needed, although I believe you can omit the area in the Url if you keep your controllers unique, but isn't that a bit smelly?

Perhaps Areas are good for medium complexity sites or when module code is better kept in one location so it can be copied to other sites or removed.

Answer 1

First, before I answer note that this is just my opinion and it's mainly about models.

The way I see it, areas can be just so evil.. If you have many areas your solution explorer becomes a maze, and it can get so hard to find something.

I suggest creating a new library project inside your solution, and put the logic in there.

The best benefit (and it's not that you can find what you're looking for much easier) is that your application becomes much more modular. If you create a library and specify a reference for it in your ASP.NET MVC application, you can't easily make a mistake and involve UI in the logic.

Answer 2

I'm not sure if that's the right question. Areas can be overkill for small projects, but it's hard to imagine a non-trivially large project not using areas to help keep classes organized.

I use MVC Areas for the enterprise and love several things about it:

1. Typically people are working on a feature within a given domain (e.g., Search, Checkout, etc). If the area names correspond with your business domains, MVC Areas help reduce the time it takes to implement a feature, because the related classes are easy to find.
2. MVC routing gives you a ton of flexibility over how how structure the URLs. I used to use the Action Controller "pattern" but for non-public facing URLs I've just fully embraced the Area default route to make things easy.
3. Areas give you the distinct advantage of styling and, more importantly, encapsulating behavior at a site-section level. Each area gets its own web config where you can control the base view page or add managed handlers.

You're absolutely right that services should be in separate projects / solutions altogether, that abstract the data access via repositories, in an environment where multiple clients can access common business functionality.

But MVC Areas are great at providing some order to the UI / routing chaos as a web project grows, which, to me, is invaluable, regardless of context.