Interview: Repository, Unit of Work, Lazy Load Pattern

Repository -

Create a wrapper around all of your data access logic with a database-agnostic interface, so that you can defer commitment to a particular datastore.

A skeptic might ask, Well how often do you actually change your entire database? Not that often. But you cache expensive functions all the time

The main benefit here is that at any time you can swap out the underlying data store by implementing the same interface in a different repository and your business logic remains unchanged.

There are other benefits worth mentioning:

• Indexing — With all of your data access logic for a table or a collection in one place, it’s very easy to spot opportunities to add indices or query optimizations.
• Cacheability — Since your data access logic doesn’t bleed into the business domain, you can very easily create higher-order functions that cache high throughput calls either in memory (careful!) or in a distributed cache.
• Reusability

In conclusion, implementing a repository is almost always a good idea because it’s very little boilerplate and you never know when you may need to make a change, add a cache, or add a little extra test coverage.

Why Unit of Work?

Unit of Work responsibility can be summed as follows:

• Expose Repositories to outside. (Centralized database access)
• Commit or dispose changes to database. (Transaction management)
• Provide database context to Repositories. (Connection management)

Any intermediate states should not be committed to database but rather all should be committed to database at end as an Unit of Work.This pattern is called Unit of Work and should be wrapped around repositories.

Lazy Loading Design Pattern

If you’re looking for ways of making your applications faster -try Lazy load.

Lazy loading is a concept where we delay the loading of object until the point where we need it.

You can use Lazy<T> to safely and concisely instantiate objects exactly when they’re first used, and can do so in a thread-safe manner i

Loading the Company object from the database along with the list of all its employees in the ContactList object could be very time consuming. In some cases you don’t even require the list of the employees, but you are forced to wait until the company and its list of employees loaded into the memory.
One way to save time and memory is to avoid loading of the employee objects until required and this is done using the Lazy Loading Design Pattern.