As I do more work at new work, I expect I will come across a few of these patterns that I don’t know about. For some reason Software Design Patterns are a trigger for my deeply ingrained Imposter - I find myself regularly having to apologise for my lack of ‘proper’ computer science knowledge. So I am going to try to learn about them!
This series is my attempt to fit ‘proper’ patterns and architecture definitions into my existing brain framework. As such it probably will rely heavily on the reader knowing exactly the same information as me which is kinda unlikely, so sorry if it doesn’t help you - it was only ever written to help me!
What do I already know?
In the good(!) old days, we talked about implementing a Data Access Layer to separate out some of our complex logic from the database itself. Now the problem with this is not the idea itself, but the fact that we didn’t actually do it very well. There was never any real distinction between the data, controllers and the front end - we ended up with business logic in surprising places and didn’t leverage the separation of responsibilities nearly enough.
What we were aiming for was something more like this:
- Database model - basic SQLAlchemy table definitions, standard functions for the data like ‘create a new complicated thing’ or ‘add a new thing only if certain business conditions are met’ and massaging the data nicely for display
- Controllers - connect the data and the front end together
- Front End - get the users input/display world
We referred to it as ‘fat models, thin controllers’
The Repository Pattern - what is this new information?
So according to many googles, a repository is just a mechanism to map data to the application. Of course it’s a bit more nuanced than that really, but in essence it’s just some nice glue that we can use to get a ‘front end’ to talk to a ‘back end’.
The way I understand it is that a repository sits between the db model and whatever other code you have and provides a simpler interface to the database, so you can read and write data easily. It is a stateless thing that takes your input or request for data in a nice straightforward way and returns whatever results in an equally straightforward way. The data could come from a proper database, redis, a flat file, you don’t need to know or care, it is masked by the repository and whatever the source the input/output/whatever methods all work in the same way. The code that interacts with the repository, to all intents and purposes, sees the repository itself as the datastore.
Final Thoughts
This does seem a bit overkill, but I think most of the examples I’ve been reading through are so simple and contrived that it doesn’t make sense to actually use this pattern. New work is still too new to comment, but I can definitely see the advantages of a design like this for old work. If nothing else, it would have solved our endless unit testing problems, because it would have helped separate out the actual database so we could truly test in isolation.
Oldest comments (0)