Asp.Net MVC5, structuring large projects. Areas?

Question

I come from an Asp.Net background and I'm evaluating Asp.Net MVC for a new project. I can't see how to structure a large project adequately.

I'm happy with the Model/View/Controller architecture and I'm presently trying to get Areas to work (which seems quite complicated for what it is).

Can you have Areas within Areas? Can you put Views in dlls?

I really need a starting point here, are there are resources which show how to structure large MVC projects, assume that eventually there will be 100+ views in the project, I don't want them all in the same folder and ideally I'd like sub folders

thanks for any help

Edit: I can see that each controller maps to a View folder, what I want is something more like this

 Areas
  Mail
    Absence
      SimpleAbsenceController.cs
      ComplexAbsenceController.cs
    Overtime
      SimpleOvertimeController.cs
      ComplexOvertimeController.cs
    Etc

Edit2: Perhaps this is more of a routing question, can I map from: http://www.mystuff.com/SimpleAbsence/Index

to Mail/Absence/SimpleAbsenceController

Fundamentally I want a way of structuring my project into folders

Answer 1

I hate answering my own question as I feel it undermines the work of others who try to help, at the same time others may look at this later and these really are newbie questions, so...

(this is all from reading Pro ASP.Net MVC5, good book)

I wanted to know how much flexibility there is in Asp.Net MVC with regard to using subfolders or dlls. This answer address the subfolders question.

Answers

1. You can put controllers where-ever you like in terms of folders on the disk, these are compiled, but...

2. When you use areas the MapRoute in the AreaRegistration.cs file automatically limits the routes to the namespace for the area. So if for example you move a controller to an area you -must- change the namespace or methods like Url.Action will fail

3. Views must stay where they are, so for a controller called Fred there must be this structure:

View
 - Fred
  - Action1 
  - Action2
  - etc

You can work around all of this using your own routing system, you could probably work around the namespace issue with a custom route, but my view is as a newbie you should work with the system until you know enough to fully understand the consequences of breaking the rules

So this means you could have a large project with a few hundred Views all lumped together in one folder. It's not quite as bad as it seems as the controllers can be in sub folders and you can directly map from them to the Views.

You also have flexibility in the routing system, so regardless where controller are on disk you can have any urls you like!

e.g. this route maps from
http://www.example.com/App/DoSomething to
http://www.example.com/Home/Something with no changes necessary

routes.MapRoute("NewRoute", "App/Do{action}", new { controller = "Home" });

NB If you do this make sure to use Html.ActionLink or Url.Action (or equivilents) as opposed to direct links, these are clever enough to generate the correct urls based on the routing.

As I say, complete newbie issues but I'm sure others will have the same questions, thanks to MiniRagnarok for his example of a real life project

Answer 2

What we're talking about here is very opinion based. I've seen people that prefer to have lots of Controllers with a mapping of every object to a Controller. I've also seen people that prefer to have tons of Views. So my example is what our team has decided to do and not necessarily the same as you would see in sample tutorials.

Take a project we did that has 200+ Views for example. The site is an auction and retail site.

Controllers
    AccountController.cs
    AdminController.cs
    AuctionController.cs
    HomeController.cs
    PhotoController.cs
    StoreController.cs
    SupportController.cs

Views
    Account
        DisplayTemplates
        EditorTemplates
            ChangePassword.cshtml
        _Favorites.cshtml
        Settings.cshtml
    Admin
    Auction
    Home
    Photo
    Shared
    Store
    Support

For us, we name all partial views with an underscore first. We also utilize DisplayTemplates and EditorTemplates. All of this really helps us keep things separate. You'll notice that our controllers are split by role or function. We were never bothered by the fact that there are many ActionResults within our controller since all of our logic is really in the models.