Is there a good rationale for the MVC folder structure and alternatives?
Most MVC / MV * frameworks I've played with, they want your source to organize something like this:
model/ FooModel.xyz BarModel.xyz view/ FooView.xyz BarView.xyz controller/ FooController.xyz BarController.xyz
organization in directories based on MVC elements rather than application object types. Some part of me always feels that life would be easier if the code was organized like this:
Foo/ FooModel.xyz FooView.xyz FooController.xyz Bar/ BarModel.xyz BarView.xyz BarController.xyz
Because, generally speaking, if I'm working on Foo (like adding a new field), I often open all Foo * files, which are tedious (world first problems) because all Foo files are in different directories.
Is it a code smell that is too tightly coupled between Foo sources?
And, of course, this alternative becomes less attractive when we have models, views, or controllers that do not have corresponding views, controllers and models. That often (usually?) Business ...
So why is the standard organization for the MV * framework really better than my suggested straw man alternative?
source to share
I was in the same dilemma. Looking at StackOverflow, What strategy do you use for naming packages in Java projects and why? there are interesting ideas, especially Uncle Bob's Design Principles for detailing . In the Principle of Shared Reuse, he says:
PACKAGED CLASSES RETURN TOGETHER. IF YOU USE ONE OF THE CLASSES IN THE PACKAGE, YOU WILL USE ALL OF THEM.
In the design package you mentioned, it makes sense to have a package model
, as this is very often used to reuse multiple model classes through Controller and View Layers. On the other hand, the package foo
cannot be reused, like the application module itself. In addition, according to the General Closure Principle :
CLASSES IN A PACKAGE MUST BE CLOSED TOGETHER AGAINST THE SAME KIND OF CHANGES. A CHANGE THAT AFFECTS A PACKAGE AFFECTS ALL CLASSES IN THIS PACKAGE.
Some technical changes, such as changing the JavaScript library or Framework Injection Framework, will have minimal impact on packages model-view-controller
(only one package needs to change) than functional (changes will propagate across packages).
source to share
Not sure about other MVC environments, but specifically for ASP.NET MVC, the views must be in a folder Views/
.
One of the principles of ASP.NET MVC is Customization Convention. The viewer expects to find views at a specific location. I believe you can override this, but it is generally best not to. (Use convention)
I think the biggest problem with this file organization is cascading changes. If I need to add a field, I need to update 5 places (model, view, viewmodel, controller, unit test). If you dig through folder trees to find these things, it can be tedious.
Perhaps the question behind the question is, "How can I navigate my solution artifacts more efficiently?" Again not sure about other IDEs, but since I'm using Visual Studio I have my own set of settings to help with this task.
In Visual Studio ctrl+,
(check comma) is great for navigating types / files / artifacts within a solution. I also use F12
it Shift+F12
to define "goto" and "find all references". I also configured the Find in Files button to display an image and text on the toolbar to make the button lighter.
source to share