Repositories and factories - Introduction

This post has been migrated, original date 09 Jun 2009 In my next few blogs I will explain how I have used factories and repositories to create entities that are easily testable and allow for a clear separation of responsibilities and are easily testable. So that it is easier to understand each components task it is best to think of each component as a real world equivalent; so a repository could be thought of as a company that produces a raw material like iron or wood, this is then shipped to a factory to make a product or entity. Like real world factories our factories may require multiple sources of raw material (repositories) to create an entity. For me this analogy makes it a lot easier to start thinking about where different responsibilities live. When designing how this works I found it best to think of how a product would normally be designed and then produced. The product is designed first before a factory is built or a source of materials found and this makes sense for our entities. I know some developers start by opening their favourite database management tool and designing tables. However by doing this you start to dictate how your entities should be structured and will cause problems later if you find that your entities don't fit this rigid setup. You may also design your application to rely on special features provided by your data source, this will cause problems if your data source changes for some reason, say a database to REST services. Once we have designed the properties on our entites we want to start thinking about how we want to get these entities, these can be thought of as order lines in the factory, and each line equates to a method we can call on the factory. So I call a method on the factory, the factory then makes requests to the relevant repositories to get the raw materials in needs to make an entity. The entity is then constructed by the factory and the entity is return to my application. The application then manipulates the entity and needs to save the changes or delete the entity. So for each entity I have a save and delete method which map to an underlying repository which is hidden by the entity. This way the application does not need to worry about where the entity is returned to it just needs to save/delete the entity and the entity takes care of itself. So in this blog I have given an overview of how my thoughts behind how I use the factories and repositories, in the next post I will give some example code on how to create a simple entity using factories and repositories.