View directory structure
A lot of times I just scroll to the top and peek definition if I need to tweak the View Model and the file’s not open already. I really like your idea of having a shortcut to the View Model when you’re in a view. Again, I appreciate what you’re going after though. Might be a little confusing, because right now a file only shows up one time in Solution Explorer. Only thing I don’t like is the controller would be repeated for each view that’s part of your controller, right? Like it would show under Create.cshtml, Edit.cshtml, etc. I like where your head’s at with that proposal. Thanks again to Bill Sorensen in the comments below who first pointed out this solution to me.
#VIEW DIRECTORY STRUCTURE HOW TO#
UPDATE : For Resharper users – click here to figure out how to fix Resharper’s intellisense. This leaves us with a much easier to maintain folder structure that allows us to stay focused and productive while writing code, and not wasting time hunting for files in different folders. The only other thing you probably want to do is run your CSS and JS through some sort of task runner (to bundle, minify, and copy to Core documentation. Move the Controllers into their respective feature folders and delete the Controllers folder Move any feature-specific View Models, JS, and CSS to their respective feature folders.ĥ.
#VIEW DIRECTORY STRUCTURE CODE#
Create a new file under this folder called FeatureLocationExpander.cs under the folder from the step above and copy the code at this gist (shown below):Ĥ. I usually call it Startup Customizations or Infrastructure and place it under the root of your csproj, but you can call it whatever you’d like.ī. Add a custom ViewLocationExpander to tell ASP.NET where to find the ViewsĪ. are not things known by MVC’s conventions, so we don’t have to worry about those, and Controllers are automatically picked up.Ģ. To do this, we simply need to do move some files around and change some configuration about Views. If a ton of people do this, why write this blog post?īecause I haven’t seen an implementation of this for ASP.NET Core. And there are many, many other people who like this structure better, even if it goes against the default conventions that Microsoft expects. Even other stack experts like Angular guru John Papa structures his apps this way. Matthew Renze wrote a blog post about doing it in ASP.NET 4.x. I actually like the word component better as a more consistent descriptor across other web stacks (such as Angular, React, etc.), but because View Components are a new feature of ASP.NET Core, the name “component” might be a bit misleading in ASP.NET Core land. Instead of “feature” you could use the word component, module, etc., but I like the word feature best in this scenario. I’ll show you exactly how to do that in ASP.NET Core. Wouldn’t it be nice for all these things that make up the feature to live in the same folder? That way, you’re just living in one folder (on the front end anyways, business logic and data access logic is likely in another project), and everything is laid out nicely next to each other. All the while, you get the sense you’re fighting your folder structure and fighting the default framework conventions. As your app grows, there are more and more files in these various folders that you have to wade through to find the files you actually need. You keep opening and closing the Controllers folder, the Views folder, the View Models (or Models) folder, the Scripts folder, the Content/CSS folder, the Shared folder under Views, etc. You’re implementing a feature, and you end up spending a lot of time bouncing between folders while you’re implementing the feature. It looks something like this:Īnyone who has built any ASP.NET MVC app of any size often runs into the same problem. A feature folder structure is easier to maintain than the default structure and even Areas (which is a poor man’s feature folder structure). A feature folder structure is organizing your app by feature as opposed to technology (Controllers, Views, etc.), which is the default structure in MVC.