Andy Butland

Previous posts in this series Rich Domain Models and Entity Framework. A CQRS Implementation with ASP.Net MVC and Entity Framework . Introduction to the series . Introduction In my previous post I discussed steps I've been taking with recent application to move more logic and behaviour into a richer domain model. This has a number of advantages, a significant one being ease of testing of this behaviour. As this is coded as methods on a standalone model class, it's very easy to test due to it's lack of dependencies. Nothing needs to be mocked or stubbed; an instance can just be instantiated in the test method and the appropriate methods called and results asserted. Given the CQRS style approach I've taken elsewhere in the applications, MVC controllers are fairly light and have less value for testing. The main part of the application where logic lies is in the individual query and command handlers. These have a tight dependency on Entity Framework thoug...

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...

A fairly simple extension I wanted to make to one of my imported entities was to provide a read-only, concatenated property. I tend to do this on any business object that represents a person to provide a single, read-only property for their full-name. In a simple C# class, it would look like this: private string mstrFirstName; private string mstrLastName; public string FirstName { get { return mstrFirstName; } set { mstrFirstName = value; } } public string LastName { get { return mstrLastName; } set { mstrLastName = value; } } public string FullName { get { return mstrFirstName + ‘ ‘ + mstrLastName; } } To implement with the Entity Framework, the first thought might be to add this same property to the class produced… but of course this class is generated automatically by the framework, and hence any changes made would be overridden. .Net’s concept of partial classes come to the rescue here. You simply make your own class with the same name as the class you wish to exte...

Have recently been getting to grips with the Entity Framework and MVC , both of which I’m using on a relatively small project to gain an understanding of the technologies and to evaluate whether we should consider either of these technologies for more major solutions at this stage in their life-cycle. There’s obviously a fair old learning curve involved, but armed with Julia Lerman’s book have made good progress with Entity Framework and thus far have been very impressed. Have run into a few issues of course, and the one giving me most grief is regard to complex types. The issue arises when, having created your model from your database you want to make some customisations to it. This is an important feature, as one of the major points of this technology should be to allow you program against a model that you (the app developer) want to use and not be completely tied to the database structure. A common requirement here would be to convert a single table (or imported entity) into two ...