Last post Jan 01, 2016 05:25 PM by PatriceSc
Dec 29, 2015 08:25 PM|AnushaPramod|LINK
What is the best Practice in creating MVC6 RC1 project Structure?
WebApplication1 in below pictures depicts the Microsoft standard.
Whereas WebApplication2 is a modified version of the MVC6 project. WebApplication2 has Modules and underneath different Features. For Instance Employee folder contains model, view, controller, and ModelView in the root
of the Employee Feature. Idea is to enable and disable features.
Now the question -
1. Is this project structure(WebApplication2) good compared to standard project structure(WebApplication1)?
2. Will there be any upgrade issues while moving to newer version of MVC or do you see any down fall in (WebApplication2) if we choose this?
3. What is the best practice to enable and disable the features with MVC6 project?
Looking forward for the suggestions...
Jan 01, 2016 05:04 PM|jammycakes|LINK
It's best not to think in terms of "what's the best practice" but in terms of "what are the advantages and disadvantages of each approach".
WebApplication1 groups files together by architectural role whereas WebApplication2 groups files together by business need.
The advantage of WebApplication2's approach is that for your most common user stories, most if not all of the files you're going to need to change together are grouped together in the same place. This is called the Common Closure Principle: classes that
change together should be bundled together. You should generally prefer this approach where possible for this reason.
The only reason you'd favour WebApplication1's approach rather than WebApplication2's approach is if you're using a framework (such as older versions of ASP.NET MVC) that strongly encourages it or even enforces it for technical reasons. For example, Controllers
and Views had to be in separate folders because MVC looked for views in the Views folder and expected them to follow a naming convention corresponding to the controller and action name.
It's very common to see solutions that adopt WebApplication1's approach where it isn't necessary. So for example, you'll find interfaces, enums, services, repositories, models, view models and so on each have their own folders and in extreme cases even their
own assemblies. This is cargo cult programming pure and simple -- it offers no real-world benefits whatsoever and just adds friction.
Jan 01, 2016 05:25 PM|PatriceSc|LINK
Or you could also use something in between such as what was done with MVC areas: