Repository Pattern

How can I explain the Repository Pattern to myself?

What is it?

The core idea of the Repository Pattern is that it is a method of encapsulating data access and moving it away from your code. Allowing the rest of your code to talk to the database using the domain objects that are moved around through the rest of the application.

A good repository will only implement the functions that are required by its consumers rather than adding functions that would be nice to have but may never be used. If you never need to update an item don't have a method for it.

What is it used for?

The Repository Pattern has several advantages:

Making code testable by encapsulating dependency on database

This allows the Repository to be mocked out in unit tests allowing the tests to run quickly without requiring complex database set up and tear downs.

Mapping from data storage to domain objects

Abstracting away the database means that complex data structures that may be used in storing the data only need to exist next to the database while the rest of the code can use meaningful data structures that model the domain.

This abstraction also allows for an required changes to how the data is stored to be limited to a single place. The example of picking a different database always seems convoluted but I have been required to add extra fields for indexing more than once.

How is it different to a Data Access Layer

The key difference between a Repository and a Data Access Layer or Tier is that the Repository implements interactions in domain language. These may at times cover multiple database operations. e.g. 
repository.StoreUpdatedItemOrder([Items])
may update the order property on each of the persisted items.

What should I watch out for?

The risk with a repository is that it can become bloated. Multiple consuming classes/functions can result in a large interface that is prone to changing or in an interface that is difficult to change for fear that the change will break one or more consumers.

Mitigations

To mitigate the risks of the Repository Pattern;
  • Keep the Repository need by adopting the YAGNI (You Aint Going to Need It) principle and only implementing the methods required for a consumer.
  • Keep consumers safe from changes by adopting the Interface Segregation Principle and Dependency Inversion Principle. Have each consumer own their own interface to the Repository and have the Repository implement these interfaces. That way a change required for a single consumer does not need to ripple out to other consumers that do not require the change.

Comments

Post a Comment

Popular posts from this blog

Solving `Empty reply from server` in DotNet Core

tldr; If you’re getting  curl: (52) Empty reply from server  check that you’ve configured Kestrel correctly. Long version I’ve started playing with Dotnet Core and Docker and have had a few issues getting started. I’ve had a little bit of experience with Docker, though only a little. I’ve worked with DotNet previously but never with Core. Environment The setup I’m using is a Windows laptop running Vagrant. Via Vagrant I’m running an Ubuntu Virtual Machine with the Docker run time installed. Feels a litle like inception. Key Problem The key problem that I’ve had getting started was having my Docker container not responding correctly to my curl commands. I get this: curl: (56) Recv failure: Connection reset by peer curl: (52) Empty reply from server Given that I’m not all that familliar with Docker or Dotnet Core I decided to remove one of the variables and set up a simple Express app in a different docker container. This validated that the commmand I was using to run
Read more

Testing functions that use local storage with Jest

Testing functions that use the browsers local storage API seems easy when you know how. Here's a quick run down on how to mock it out with Jest if, like me, you're not familiar with how to test it. In the end it's very little code. Consider the following TypeScript code. import { get, save, key } from "./storage"; describe(save, () => { let setItem: jest.Mock; beforeEach(() => { setItem = jest.fn(); Storage.prototype.setItem = setItem; }); it("should call set item with predefined key and json object", () => { const valueToStore = { value: "toStore" }; save(valueToStore); expect(setItem).toHaveBeenCalledWith(key, JSON.stringify(valueToStore)); }); }); The key lines are in the beforeEach call where the setItem function of the Storage prototype is assigned to an instance of jest.fn() . This allows us to make assertions on what is passed to the local storage setItem API.
Read more

Building a verify JWT function in TypeScript

# Verifying an RS232 signed JWT JSON Web Tokens (JWT) are used as a way to verify the identity of the caller of an API. **The best way to verify a JWT is to use a verification library.** I wanted to have a look at some of what those libraries are doing under the hood by putting together a function that will return if a given token is valid. In this blog I'll go through what I have done to get a validation function working. To simplify things assume: - That the signing algorithm is RS232 all others are considered invalid. - That the public keys are available on a JWKS url provided to the function eg [https://klee-test.au.auth0.com/.well-known/jwks.json](https://klee-test.au.auth0.com/.well-known/jwks.json) - I only want to know if the token was signed by a key available at the above url. I wont be checking if the token has expired, if the scopes or other claims are valid. # Break up the token A JWT is made up to 3 parts. The first thing to do in validating the token is to brea
Read more