ASP.Net MVC Principles - Part 4
In our last article we described the Service and Presentation layer choices in our ASP.Net MVC application template. In our fourth and final article on ASP.Net MVC Principles, we discuss BHW's Visual Studio project template and how it helps us quickly start projects with a great foundation. We also discuss when to apply the template and some of the value the template brings to our projects.
In 2010 BHW built our first ASP.Net MVC project template. That template included NHibernate, Automapper, Castle Windsor, and Bootstrap. Two years later we released our second template, and this time we decided to make it easier for our team to start new projects with our best practice recommendations. We accomplished ease-of-use by baking our template into a Visual Studio project template. It’s a great feeling to launch Visual Studio and see our template listed as an option under ‘New Project’. Check out Paul’s article for more on how we did this.
When to apply the template
Do we use the template on every project? Of course not, but the template does seem to fit a sweet spot for us based on our typical project complexity and size. We are a consulting company and our clients hire us for challenging projects. On some of these projects we’re the only development contributor, but on others we are part of an integrated team. In both cases we feel that having a template based on SOLID principles makes us more successful, and surveys of our team shows they feel more productive as well.
Obviously the template we’ve described here is only a fit for the Microsoft stack, but the principles detailed here are easy to follow in other frameworks. The popularity of MVC programming frameworks means that we can apply these approaches when we work in Rails, Pyramid(Pylons), Laravel, and many others. The component selection varies for other frameworks and sometimes heavy components aren't required, for example IoC containers are generally not used in dynamic languages like Ruby or Python. Regardless, SOLID techniques can still be applied to all these frameworks.
In larger teams there are definite advantages to having shared coding standards that allow the majority of your team to be instantly comfortable if they switch projects. Using a template approach based on your platform’s principles definitely helps adhere to your standards. On the other hand, if you are a one-person team you may not use many of the advantages provided in the template's abstraction layers. In this case, heavier techniques like using a repository pattern for data access, may be unnecessary.
There’s also a trend toward simplifying .Net projects by removing unnecessary abstraction layers. Two driving forces that we have seen in this trend are the popularity of NoSQL document databases, and the maturing of integration test solutions on the .Net platform. NoSQL drivers provide query interfaces with rich and distinct mechanisms for querying data. Hiding these interfaces behind a data access layer based on a repository pattern isn’t always a great idea. You can lose many of the advantages of one NoSQL option versus another when you try to abstract and commoditize these interfaces. The second driving trend, integration testing, is going to be the subject of a future article. The integration testing options have matured so much that there is less emphasis on abstraction for ease of unit testing and more attention on complete end-to-end testing.
We underestimated the benefit of automating project creation in Visual Studio when using our template. Prior to our template we often would consider using an older project as a starting point, ripping everything out to get to a starter template. We were too quick to discount how much time this process requires. After really analyzing this process, it’s not uncommon to spend two or more hours removing code, removing assets, changing properties, etc. If you weren’t familiar with the template to begin with it would be much longer. The hours we spent on this process quickly add up when you consider the number of projects our team starts in a year. We also feel that the template encourages us to follow SOLID principles throughout the project. SOLID code helps us produce higher quality deliverables, delivering more value for our clients.
Thanks for sticking with us through our four part series on our ASP.Net MVC Principles. We’d love to hear your comments. Please let us know if articles like these are interesting to you, and feel free to suggest other topics for us to write about.
Do you need an expert in web development? With a team of web development specialists covering a wide range of skill sets and backgrounds, The BHW Group is prepared to help your company make the transformations needed to remain competitive in today’s high-tech marketplace.