I am fairly new to the Repository pattern (just got back from stone age, hi everyone :-). My dilemma is that I am need to develop a way my Windows Store app work with SQLite (SQLite-Net) today, and in a near future work off WCF services (or some non-direct database access). Basically I want to switch provider for my data access layer easily.
The best site I came across with example is this blog (http://blog.longle.net/2013/05/11/genericizing-the-unit-of-work-pattern-repository-pattern-with-entity-framework-in-mvc/) But like any other place it still have heavy dose of Entity framework which I don't think applicable to my situation.
Can someone point out possible solutions or references that I can further work on ?
Thanks
The single best reason to not use the repository pattern with Entity Framework? Entity Framework already implements a repository pattern. DbContext is your UoW (Unit of Work) and each DbSet is the repository. Implementing another layer on top of this is not only redundant, but makes maintenance harder.
The unit of work class serves one purpose: to make sure that when you use multiple repositories, they share a single database context. That way, when a unit of work is complete you can call the SaveChanges method on that instance of the context and be assured that all related changes will be coordinated.
A generic repository is a type that comprises of a set of generic methods for performing CRUD operations. However, it's just another anti pattern and is used frequently with Entity Framework to abstract calls to the data access layer.
Unit of Work is the concept related to the effective implementation of the repository pattern. non-generic repository pattern, generic repository pattern. Unit of Work is referred to as a single transaction that involves multiple operations of insert/update/delete and so on.
Welcome back! I hope the food was good. :-)
You can implement the Repository pattern by writing your own data access layer (DAL) as an interface, and then just writing adapter classes to SQLite and WCF respectively, that both implement that interface. Your interface(s) would define query methods and update methods. For example, you can write the following:
public interface IWidgetRepository
{
// Query methods
Widget GetById(string id);
IEnumerable<Widget> GetFeaturedWidgets();
IEnumerable<Widget> GetRecommendedWidgetsForUser(string userId);
// Update methods
void RenameWidget(string id, string newName);
void UpdateWidgetPrice(string id, decimal newPrice);
}
See also this answer on a similar question; it goes into some more detail. You're in the same situation as in that question, even though it looks different on the surface because you're coming from a different starting point. But the solution is the same once you see how the underlying pattern works.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With