Andy Butland

Previous posts in this series A CQRS Implementation with ASP.Net MVC and Entity Framework . Introduction to the series . Working with a Rich Domain Model and Entity Framework As described in previous posts in this series, I'm documenting a few changes to the way I've recently been building out ASP.Net MVC applications, following various influencers from blogs and books. One area I was keen to look at was creating a rich domain model - inspired by the Eric Evans classic book and some posts by Julie Lerman and Jimmy Bogard. Previously I would have worked more with what is known as an anaemic domain model - which isn't quite as bad as it sounds... but means that when creating entities for use in Entity Framework Code First, they would in the most part be made of a simple set of properties with public getters and setters. With a rich domain model, we look to push more behaviour into these model classes and provide tighter means of control over their use by callin...

Previous posts in this series Introduction to the series . Considering a CQRS approach with ASP.Net MVC Even a quick read of the various blog posts and other web based information on using CQRS with .Net reveals it can mean a lot of things to different people. To my understanding, at scale, it's a recognition that your read and write operations are likely to require quite different approaches. Reads for example may be coming from denormalised or cached information, and writes might go to queues for subsequent processing. Which is all a bit removed from a more basic CRUD approach where we simple read and write to the database. In truth though, I didn't need - at least yet - these type of performance improvements. Nonetheless, there remains value for me even in a smaller-scale application in handling query and command operations more distinctly . Which really means in practice that rather than having a service and/or repository layer that provides methods such as G...

Having spent a bit of time working on CMS (Umbraco and EPiServer) based projects, I recently had to come back to building a custom ASP.Net application using the MVC framework. Before commencing I took a bit of time to read around, and re-think some of the ways I've built applications like this previously, in terms of how the solution is architected. Previously I've put together a fairly strict three layered architecture - data access layer using Entity Framework, wrapped in a unit of work/repository pattern; a business logic or service layer, and the presentation web application. Which worked quite nicely in truth, but there's always value in re-looking at such things and seeing how they could be improved. And where's the fun in doing things the same way each time anyway! In particular I was keen to investigate: A CQRS style architecture , where we work with distinct query and command objects, in a more "slices over layers" fashion. This breaks the ...

Having recently upgraded a couple of ASP.Net MVC 2 projects to MVC 3, I came across a couple of tools and techniques to simplify the process. ASP.Net MVC 3 requires .Net 4 and hence use of VS.Net 2010 (or express editions) are required. There's also an additional download of the MVC 3 framework required too. One of the simplifying changes of the upgrade is a slimmed down web. config file - but I found this meant an in-place upgrade of this and all the necessary references rather complicated. So instead I created a new, empty MVC 3 project and copied over all the controllers, models, views and necessary web. config settings into the new project. An important security update is to HTML encode all output by default, using the new <:= > syntax (as opposed to <%= %>). If you've been encoding output properly in previous versions any potentially insecure content would have been wrapped in Html.Encode methods. But updating all of these to the new syntax looks to be...

I've blogged previously about the validation methods I've used on ASP.Net MVC projects and have recently been adapting this for use with version 2 of the framework. One of the new features I wanted to make available was the use of data annotations for validation , where domain or view model classes can be decorated with attributes for validation of required fields, field lengths and range values. These can then be used for both server side and client side validation . I ran into a problem with this though when validating entities that had related items - for example in my case I was working on a project management tool, where an entity such as a project is related to others such as a client and an account manager . The client entity has required fields such as a name, but when validating before saving the project entity I didn't really care about that as I was only interested in the client ID to perform the update operation. The validation by default is set up to perfor...

With its clean model for separation of concerns, one of the things I’ve been impressed by in use of MVC with ASP.Net is the support for building AJAX enabled applications that support progressive enhancement. This technique takes the traditional strategy of graceful degradation in web design and turns it on its head. Rather than focussing on having the best possible user interface degrade to a less rich but still workable and presentable one, the focus is on creating a functional base UI that is enhanced by the addition of CSS and JavaScript to produce an improved user experience for those that can make use of it. Of course either method can lead to the same result, but – in addition to the use of some specific techniques such as external referencing of assets to avoid swamping the more basic client with code or data that can’t be used – the change of approach leads to a different design mindset and result that better supports the full user base. In this post I’ll illustrate a sma...

Up to now in developing web applications using ASP.Net MVC I've eschewed the use of View Models and have simply passed my Domain Model objects into views, along with supplementary information as needed in the ViewData Dictionary . This technique allows the domain model object to be be made available in a strongly typed manner within the view, and to use model binding to put the object back together following form posts for create and update methods. Certainly for the scale of application I've built so far this works just fine. In cases where I want to use additional information passed in the loosely typed ViewData dictionary, I'm able to cast to a typed variable at the top of the view in order to use it in a strongly typed manner from then on. And if I've needed to pass additional information back from my form posts, these can be added as additional parameters to the controller action set up to receive the post. The following code illustrates this. The first meth...