As a project grows, there are certain areas of the code-base that becomes brittle – that is, they become real hassle to change. But, in an Agile process, we need to be able to evolve any area of the code at any time, with (hopefully) minimal impact. How can we do this?
One technique we’ve adopted on recent projects could be called “Fake it till you Make it”, or “Fake Injected Repository Test-Driven-Development”. Whatever the name, it’s working pretty well.
The main brittle point we are trying to overcome is the persistence layer. Even with a Repository pattern to hide the details of persistence from the domain, subtle changes in the domain classes can lead to time consuming changes in the persistence code, mainly in the mapping between the database and the domain classes. To make things more complex, our project already has a large database with tens of thousand of records. While we can make changes to the schema, we also need to write data migration code that moves data from the current schema to any new schema. So, changes to the domain can have wide reaching effects.
Since our code evolves sprint to sprint, we can have some large scale changes in our domain model on a very regular basis. We wanted to wait until the last possible moment before we actually “committed” to a database design, and an actual implementation of the data persistence layer (not to mention, changing the data migration scripts)
Our Solution (Short Version)
The solution we have come to is to “fake” the repository until we are satisfied with the design & behavior of the domain layer, and THEN update the data migration scripts, and THEN create the real implementation of the repository. This allows us to refactor, rename, and generally go hog-wild with the domain classes, streamlining things as we discover how the application actually wants to work with them, before touching the database and the ETL code.
That’s the quick summary. The rest of the post looks at how we are implementing this. I’m working with ASP.NET MVC, so that’s the context, and any reference to a “Controller” is in that context, not a “data controller” which are common in other data access models.
Interfaces and Dependency Injection
As I mentioned, we use interface based repositories to separate the persistence details from our application code (the “domain” if you will).
This separation give us a lot of good things, not the least of which is the ability to mock the repositories in our unit tests (because we use interfaces). But before we get to that, we have the issue of getting the repository into our domain, and for that we use dependency injection.
For those not familiar with it, just think about it is as a fancy name for passing required external dependencies to a class by it’s constructor.
So – for example, in our MVC applications, our controllers orchestrate the actions with the domain, and thus they require access to the repository. So, the constructors for our controllers take various repositories…
/// <summary>
/// Initializes a new instance of the <see cref="LoginController"/> class.
/// </summary>
/// <param name="authenticator">The authenticator.</param>
public LoginController(IAccountRepository accountRepository)
{
_accountRepository = accountRepository;
}
So, in this code, our LoginController class requires an IAccountRepository. We use Castle Windsor and some MVCContrib classes to wire this all up, but that’s for another post. The main thing here is that we are passing in the data repository as an interface.
The Interface
At this point, our interface is still pretty lean – we only add what we need in the code at any time. This is following with the Test-Driven and Agile ideals of building just what you need when you need it. Thus we don’t have all sorts of other GetAccountBy… methods on the interface. Also, we have not gotten to the point of updating Users, so you won’t see any UpdateUser methods either.
/// <summary>
/// Interface defining all interactions with Use Accounts
/// </summary>
public interface IAccountRepository
{
/// <summary>
/// Authorizes the user.
/// </summary>
/// <param name="username">The username.</param>
/// <param name="password">The password.</param>
/// <returns></returns>
User AuthorizeUser(string username, string password);
/// <summary>
/// Gets the menus that this user has access to
/// </summary>
/// <param name="user"></param>
/// <param name="baseUrl"></param>
/// <returns></returns>
IList<MenuItem> GetMenusForUser(Customer user, string baseUrl);
/// <summary>
/// Gets the customer by id performing a deep load of all contained collections.
/// </summary>
/// <param name="customerId">The customer id.</param>
/// <returns></returns>
User GetCustomerById(int customerId);
}
Faking It
During the sprints in which we need to mix up the domain classes, we will run with “Fake” implementations of the repositories. Quite simply, a “Fake” is a real implementation of an interface, but instead of returning real data, or running real functions, it returns canned “fake” data. This is really handy because it’s very easy to update the FakeRepository – after all, it’s just code – no database tables, stored procs, primary keys, or migration code to mess with.
During this phase, we focus our efforts on driving the design of the domain with unit tests and UI integration. Since the FakeRepository get’s injected into the application just like a real one would, we can actually run the application. This allows us get feedback from clients, before investing time in building out the persistence tier. This is a huge time savings and allows us to prototype things faster and easier than before.
Of note, we still use Mock’s of the Repositories in our Domain unit tests, so we are cleanly separated from our Fakes. We do this so that our tests will continue to run regardless of changes to the “fake” data which may be returned from the FakeRepositories.
/// <summary>
/// Authorizes the user.
/// </summary>
/// <param name="username">The username.</param>
/// <param name="password">The password.</param>
/// <returns></returns>
public Customer AuthorizeUser(string username, string password)
{
//Create organizations
IList<Organization> orgs = new List<Organization>();
orgs.Add(new Organization("DTS", "DTS"));
orgs.Add(new Organization("Dev", "DEV"));
IList<Role> roles = new List<Role>();
User user = null;
switch (username)
{
case "admin@edats.com":
roles.Add(new Role(RoleEnum.ApplicationAdministrator));
roles.Add(new Role(RoleEnum.Researcher));
break;
case "agency@edats.com":
roles.Add(new Role(RoleEnum.AgencyReviewer));
break;
case "user@edats.com":
roles.Add(new Role(RoleEnum.Researcher));
break;
default:
return null;
}
user = new User(null, "deFaker", "Luke", "Luke deFaker", roles,orgs);
user.UserId = 1;
return user;
}
In this code above, we have some simple logic that will let us log into the site as 3 different users, who have different sets of roles in the system. It’s all fake, but it it allows us to build out the application and more of the domain classes.
Needing It
Once we are at a point in a sprint that the domain is stable, we then push the changes back into the real repository implementation, and change our data migration scripts. Since we know the interface, we can do this work very test-driven, which leads to very lean data access layer code. We know exactly the methods that the Domain requires, so that’s all we implement.
In this system, we are using SubSonic in the implementation of the Repository. The code below shows some of the implementation (you can read more of this over at Brian Noyle’s blog)
/// <summary>
/// Authorizes the user.
/// </summary>
/// <param name="username">The username.</param>
/// <param name="password">The password.</param>
/// <returns></returns>
public User AuthorizeUser(string username, string password)
{
//this method just returns a shallow user with roles
Domain.user result = null;
if (string.IsNullOrEmpty(username) || string.IsNullOrEmpty(password))
{
return result;
}
//get the user using subsonic query
result = RepositoryUtility.BuildPocoTypeFromRepoType<Domain.User>(DB.Select(). From<User>().
Where(User.UsernameColumn).IsEqualTo(username).
And(User.User_PasswordColumn).IsEqualTo(password).
And(User.IsActiveColumn).IsEqualTo(true).
ExecuteSingle<User>(), true);
if (result != null)
{
result.Roles = GetRolesForUser(result.UserId);
}
return result;
}
Summary
Thus far, this has been working pretty smoothly. We get the flexibility when we need it, and don’t have a lot of un-necessary churn on the data access tier. We can switch between the fakes and the real Repositories by just changing a few lines in our Global.asax file. Simple. Sane and Highly Testable – everything we are looking for. Will it skin your cat? I can’t say, but the general idea can likely be applied.
With the global economy in shambles, the old-guard of industry on the rocks (Wall Street financial giants, Detroit Automakers, and all manner of “industry-leaders” in-between) and a new president taking office in a few weeks, the one thing you can say about the upcoming year is that things will change. Big time.
