I'm getting ready to take the bend out of asp and into an mvc framework, asp.net mvc or nancy. Wherever I go, I see folders for controllers/modules and folders for views. Is this just a pavlovian reflex of tidying things away by type, or is there some deeper wisdom operating? I have a little proof-of-concept project where I store together the files I'm likely to open together, a considerable comfort. Since these files are also likely to call each other, they can do so with shorter, less brittle, relative links. This pattern is challenged by mvc, because the folder path no longer automatically corresponds to the url path, and, in asp.net mvc, the project templates and routing enforce the views\ controllers\ schism.
This microsoft page introduces the concept of areas. It can be read as an admission of how unwieldy large apps become because of this artificial separation.
People will object "separation of concerns", but separation of concerns is already achieved by having separate source files. There's no concrete gain, it seems to me, from taking these source files that are tightly coupled, and sending them to opposite ends of the folder structure?
Is anyone else fighting this? Any tips?
Best Answer
I'd like to say it's cargo cult programming, but there are technical reasons for this structure. Asp.Net MVC took a convention over configuration approach to nearly everything. By default, the Razor view engine searches the
Viewsdirectory in order to resolve which view to return from the controller. There are however a few hacks to get a different project structure and Microsoft even provides an MVC feature called Areas to let us create a more sane project structure. You could also implement your own view engine in order to specify where to look for views.Why do I say that it's cargo cult programming and that you're correct about this? Uncle Bob convinced me that the project's directory structure shouldn't tell me that it's an MVC application. It should tell me that it's a store front, or a time off request system, or whatever. The high level structure and architecture should tell us about what this thing is, not how it was implemented.
In short, I believe you're right about this, but any other directory structure would simply be fighting against the framework and trust me when I say that you don't want to try to make the Asp.Net MVC framework do something it wasn't designed to do. It's a pity that it's not more configurable really.
To quickly address architectural concerns, I do still believe that the business models (business, not view) and the DAL should live in a separate project/library that gets called from your MVC app.
It's just that the controller really is very tightly coupled with the view and likely to be modified together. We're all wise to remember the difference between coupling via dependency and logical coupling. Just because the code has had its dependencies decoupled doesn't make it less logically coupled.