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.
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:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With