Constructing a DAO

A very common object to have in your application is a data access object (DAO). This object is a way to map the data from you storage mechanism (typically a database) to an actual object in your code. A DAO should be a rather dumb object and should not contain any actual logic, as the only purpose of this object is to represent the format in which data is stored. So how do you construct such an object?

A simple approach is to just use the default empty constructor and have setters and getters for each field. Creating an object is done with the empty constructor and copying all data from your domain object to this object and vice versa. This logic is typically placed in a mapper to have it nicely grouped and separate from your actual logic. This way you can have multiple mappings, from different source objects or to different target objects.

A nice advantage of this approach is that updating or creating a new object can be done in basically the same way. You just take the data copy it into your DAO, the only difference is in how you treat your id. And this is where things start to become weird. The id is typically something you let the database generate for you, so when creating a new object you should not be able to set the id yourself. You can enforce this by not having a setter on the id (which I always do), this does however that an update always has to start from the existing DAO as you can not set the id yourself. I don't find this to be a problem as you normally perform existence and/or access checks on the object.

Where this approach really starts to fall down is for entries which should not be updatable. You need the setter so you can set the initial value, but after that the setter becomes a problem. It does not clearly express that the data is immutable and will cause either an exception when saving the data, or the data will simply be ignored. I have mostly resolved this problem by having different constructors, such that they included at least all elements that can not be updated anymore. This means that all fields can be set (either through the constructor or using the setters) and only the fields that can be updated have a setter.

An alternative approach I have thought about was having the DAO construct or update itself based on a domain object. It can simply get the data from the domain object and update itself, that way it can enforce all constraints itself and we don't have to expose any setters. This means we can get rid of all the mappers and incorporate the logic in the DAO itself.

My current approach is to have expressive constructors combined with setters on all fields that can be modified. The logic to update and create a DAO is located in a mapper class. I did discover that this does have an impact on testing. It becomes impossible to create a DAO for testing purpose with a specific id as there is no way for my code to set it. The only solution I have found so far was to use a mock and mock all getters which is rather cumbersome.

There are a couple of other questions regarding DAOs which I will examine in a next blog post. Let me know if you have a different clean approach to constructing and updating DAOs.