More and more I’m finding myself getting lost in
the files in some of my larger Web projects. There’s so much freaking content to deal with – HTML Views, several derived CSS pages, page level CSS, script libraries, application wide scripts and page specific script files etc. etc. Thankfully I use Resharper and
the Ctrl-T Go to Anything which autocompletes you to any file, type, member rapidly. Awesome except when I forget – or when I’m not quite sure of
the name of what I’m looking for. Project navigation is still important. Sometimes while working on a project I seem to have 30 or more files open and trying to locate another new file to open in
the solution often ends up being a mental exercise – “where did I put that thing?” It’s those little hesitations that tend to get in
the way of workflow frequently. To make things worse most NuGet packages for client side frameworks and scripts, dump stuff into folders that I generally don’t use. I’ve never been a fan of
the ‘Content’ folder in MVC which is just an empty layer that doesn’t serve much of a purpose. It’s usually
the first thing I nuke in every MVC project. To me
the project root is where
the actual content for a site goes – is there really a need to add another folder to force another path into every resource you use? It’s ugly and also inefficient as it adds additional bytes to every resource link you embed into a page. Alternatives I’ve been playing around with different folder layouts recently and found that moving my cheese around has actually made project navigation much easier. In this post I show a couple of things I’ve found useful and maybe you find some of these useful as well or at least get some ideas what can be changed to provide better project flow.
The first thing I’ve been doing is add a root Code folder and putting all server code into that. I’m a big fan of treating
the Web project root folder as my Web root folder so all content comes from
the root without unneeded nesting like
the Content folder. By moving all server code out of
the root tree (except for Code)
the root tree becomes a lot cleaner immediately as you remove Controllers, App_Start, Models etc. and move them underneath Code. Yes this adds another folder level for server code, but it leaves only code related things in one place that’s easier to jump back and forth in. Additionally I find myself doing a lot less with server side code these days, more with client side code so I want
the server code separated from that.
The root folder itself then serves as
the root content folder. Specifically I have
the Views folder below it, as well as
the Css and Scripts folders which serve to hold only common libraries and global CSS and Scripts code. These days of building SPA style application, I also tend to have an App folder there where I keep my application specific JavaScript files, as well as HTML View templates for client SPA apps like Angular. Here’s an example of what this looks like in a relatively small project:
The goal is to keep things that are related together, so I don’t end up jumping around so much in
the solution to get to specific project items.
The Code folder may irk some of you and hark back to
the days of
the App_Code folder in non Web-Application projects, but these days I find myself messing with a lot less server side code and much more with client side files – HTML, CSS and JavaScript. Generally I work on a single controller at a time – once that’s open it’s open that’s typically
the only server code I work with regularily. Business logic lives in another project altogether, so other than
the controller and maybe ViewModels there’s not a lot of code being accessed in
the Code folder. So throwing that
off the root and isolating seems like an easy win. Nesting Page specific content In a lot of my existing applications that are pure server side MVC application perhaps with some JavaScript associated with them , I tend to have page level javascript and css files. For these types of pages I actually prefer
the local files stored in
the same folder as
the parent view. So typically I have a .css and .js files with
the same name as
the view in
the same folder. This looks something like this: In order for this to work you have to also make a configuration change inside of
the /Views/web.config file, as
the Views folder is blocked with
the BlockViewHandler that prohibits access to content from that folder. It’s easy to fix by changing
the path from * to *.cshtml or *.vbhtml so that view retrieval is blocked:<system.webServer>
<handlers>
<remove name="BlockViewHandler"/>
<add name="BlockViewHandler" path="*.cshtml" verb="*" preCondition="integratedMode" type="System.Web.HttpNotFoundHandler" />
</handlers>
</system.webServer>
With this in place, from inside of your Views you can then reference those same resources like this:<link href="~/Views/Admin/QuizPrognosisItems.css" rel="stylesheet" />
and<script src="~/Views/Admin/QuizPrognosisItems.js"></script>
which works fine. JavaScript and CSS files in
the Views folder deploy just like
the .cshtml files do and can be referenced from this folder as well.
Making this happen is not really as straightforward as it should be with just Visual Studio unfortunately, as there’s no easy way to get
the file nesting from
the VS IDE directly (you have to modify
the .csproj file).
However, Mads Kristensen has a nice Visual Studio Add-in that provides file nesting via a short cut menu option. Using this you can select each of
the ‘child’ files and then nest them under a parent file. In
the case above I select
the .js and .css files and nest them underneath
the .cshtml view.
I was even toying with
the idea of throwing
the controller.cs files into
the Views folder, but that’s maybe going a little too far :-) It would work however as Visual Studio doesn’t publish .cs files and
the compiler doesn’t care where
the files live. There are lots of options and if you think that would make life easier it’s another option to help group related things together.
Are there any downside to this? Possibly – if you’re using automated minification/packaging tools like ASP.NET Bundling or Grunt/Gulp with Uglify, it becomes a little harder to group script and css files for minification as you may end up looking in multiple folders instead of a single folder. But – again that’s a one time configuration step that’s easily handled and much less intrusive then constantly having to search for files in your project.
Client Side Folders
The particular project shown above in
the screen shots above is a traditional server side ASP.NET MVC application with most content rendered into server side Razor pages. There’s a fair amount of client side stuff happening on these pages as well – specifically several of these pages are self contained single page Angular applications that deal with 1 or maybe 2 separate views and
the layout I’ve shown above really focuses on
the server side aspect where there are Razor views with related script and css resources.
For applications that are more client centric and have a lot more script and HTML template based content I tend to use
the same layout for
the server components, but
the client side code can often be broken out differently.
In SPA type applications I tend to follow
the App folder approach where all
the application pieces that make
the SPA applications end up below
the App folder.
Here’s what that looks like for me – here this is an AngularJs project:
In this case
the App folder holds both
the application specific js files, and
the partial HTML views that get loaded into this single SPA page application.
In this particular Angular SPA application that has controllers linked to particular partial views, I prefer to keep
the script files that are associated with
the views – Angular Js Controllers in this case – with
the actual partials. Again I like
the proximity of
the view with
the main code associated with
the view, because 90% of
the UI application code that gets written is handled between these two files.
This approach works well, but only if controllers are fairly closely aligned with
the partials. If you have many smaller sub-controllers or lots of directives where
the alignment between views and code is more segmented this approach starts falling apart and you’ll probably be better
off with separate folders in js folder. Following Angular conventions you’d have controllers/directives/services etc. folders.
Please note that I’m not saying any of these ways are right or wrong – this is just what has worked for me and why!
Skipping Project Navigation altogether with Resharper
I’ve talked a bit about project navigation in
the project tree, which is a common way to navigate and which we all use at least some of
the time, but if you use a tool like Resharper – which has Ctrl-T to jump to anything, you can quickly navigate with a shortcut key and autocomplete search.
Here’s what Resharper’s jump to anything looks like:
Resharper’s Goto Anything box lets you type and quick search over files, classes and members of
the entire solution which is a very fast and powerful way to find what you’re looking for in your project, by passing
the solution explorer altogether. As long as you remember to use (which I sometimes don’t) and you know what you’re looking for it’s by far
the quickest way to find things in a project. It’s a shame that this sort of a simple search interface isn’t part of
the native Visual Studio IDE.
Work how you like to work
Ultimately it all comes down to workflow and how you like to work, and what makes *you* more productive. Following pre-defined patterns is great for consistency, as long as they don’t get in
the way you work. A lot of
the default folder structures in Visual Studio for ASP.NET MVC were defined when things were done differently. These days we’re dealing with a lot more diverse project content than when ASP.NET MVC was originally introduced and project organization definitely is something that can get in
the way if it doesn’t fit your workflow. So take a look and see what works well and what might benefit from organizing files differently.
As so many things with ASP.NET, as things evolve and tend to get more complex I’ve found that I end up fighting some of
the conventions.
The good news is that you don’t have to follow
the conventions and you have
the freedom to do just about anything that works for you.
Even though what I’ve shown here diverges from conventions, I don’t think anybody would stumble over these relatively minor changes and not immediately figure out where things live, even in larger projects. But nevertheless think long and hard before breaking those conventions – if there isn’t a good reason to break them or
the changes don’t provide improved workflow then it’s not worth it. Break
the rules, but only if there’s a quantifiable benefit.
You may not agree with how I’ve chosen to divert from
the standard project structures in this article, but maybe it gives you some ideas of how you can mix things up to make your existing project flow a little nicer and make it easier to navigate for your environment. © Rick Strahl, West Wind Technologies, 2005-2014Posted in ASP.NET MVC
Tweet
!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");
(function() {
var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true;
po.src = 'https://apis.google.com/js/plusone.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s);
})();
