Umbraco development structure/architecture

It’s been over a year now since I decided settle down as an independent webdeveloper. Basically, it was just pure coincidence that I started developing Umbraco-based sites, but as we all know, Umbraco is quite addictive once you get the hang of the endless possibilities as a developer.

Now, in this first year as an independent webdeveloper I’ve seen a lot of good stuff out there and certainly a lot of bad stuff aswell! I have seen well-structured Umbraco solutions with just the right (amount of) patterns used and a very welldefined structure matching the ambitions of the solution. Sadly, I’ve also seen what I would like to define as “the ASP.NET developer building a huge website in addition to Umbraco” trying to ignore the Umbraco API at all costs. Don’t get me wrong here, there’s definitely some great ASP.NET/C# developers out there – it’s just a shame they don’t seem to take their time to acquaint themselves with the documentation.

With that said, I don’t consider myself as a software-architect (or some sort of fancy title like that). I still have a lot to learn when it comes to software architecture. However, I think it would be interesting to start an open discussion on how to structure an Umbraco solution and share some experiences across the awesome community. I do know that it’s not all sites that needs 5+ or 10+ different class libraries in Visual Studio ;-) After all, we are blessed with a lot of built-in plug-and-play stuff in Umbraco to set up small sites.

I’d like to share how I generally set up a structure for a medium-sized Umbraco solution.

The screenshot below shows the solution in VS2010 that I typically use:

I think the names of the libraries are pretty self-explanatory and typically we could leave some of them out depending on the needs of the solution. I.e. the Interfaces, Model and DAL could be left out if no custom tables/databases are required, the Events library can be left out if we don’t need to hook up on any of the Umbraco events and so on so forth.

Although we could leave some of these libs out, I like to have them there anyway since requirements can/will be changed as the project goes on. Also, some might say that it’s totally overkill to have these libraries, but I actually find it pretty convenient once you have your post build events set up to copy the dll’s.

It would be interesting to know your opinion on this topic and eventually start a discussion on best-practices. I bet there’s just as many ways to structure an Umbraco solution as there are developers out there ;-)

This entry was posted in ASP.NET, Umbraco CMS. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. Posted October 24, 2011 at 7:51 am | Permalink

    Your structure looks good, though I wouldn’t necessarily feel I needed all of it for every project. I find my solutions evolve over time depending on the project and where Umbraco is at (for instance, now with Razor you might find I’d have a Razor Extensions class, or an @helpers class in App_Code (I think that’s the only place you can put them).

    There’s also the debate about whether you have one project broken down into multiple classes, or multiple projects broken down into related classes. The latter is more difficult to manage but a little more flexible in that you can mix’n'match by adding and removing projects.

  2. Sean Dooley
    Posted December 15, 2011 at 12:38 pm | Permalink

    Your structure has helped me understand how to setup a Umbraco project in Visual Studio.

    I do think it would be a great help if you could state what each type of project is. For example, ASP.NET Web Application or Class Library

    Great article!

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

9 - = six