I have been using Symfony2 with Doctrine2 for some years. I have recently started using Microsoft's Entity Framework with MVC5. From my Symfony2 experience I understand that a repository's job is only to retrieve and return objects, no additional operations like Saving. Now every examples I have seen for EF has a method Save/Update as part of the repository.

For symfony I have been creating manager classes as follows:

interface IManager
    function getClassName() ;
    IRepository getRepository() ;
    function Save(object);
    function Update();

So I pass around the manager, if I need to retrieve objects I call the repository directly. If I need to save I call the manager's save method.

Is a repository supposed to support save/update? What do you think of my IManager class, should I also use it for EF?

  • It depends on what your definition of repository is. One version: "A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. ... Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes."
    – Eric King
    Sep 3, 2014 at 22:31

2 Answers 2


Entity Framework is not the implementation of Repository Pattern. EF is the Object Relational Mapper. Yes, it looks and behaves like Repository Pattern with Save/Update functionality.

Your IManager makes sense, and with enough abstraction, the Manager doesn't have to be coupled to EF at all. That will give you an option of switching ORMs if needed.

  • Your language is a bit sloppy. True, EF is not Repository Pattern, but it's not a poor imitation of Repository pattern either. You can write a repository for EF, just as you can with any other object-relational mapper. Sep 3, 2014 at 21:17
  • Spoiler: nobody ever actually switches ORM. YAGNI. Feb 24 at 6:50
  • If it walks like a duck and talks like a duck, it's a duck. Implementing the repository pattern does not mean implementing nothing but the repository pattern. DbSet<T> (which is part of EF) is an implementation of the repository pattern (similarly, the DbContext is the implementation of a unit of work). That's not to say that you shouldn't wrap it in a homebrew repository pattern so as to abstract the dependency on the ORM (it can be argued both ways, depends on your use case), but I disagree with the notion that EF does not implement the repository pattern.
    – Flater
    Feb 29 at 4:52
  • @PhilipKendall: Were you there when we moved to .NET Core and EF Core lagged significantly behind the features that classic EF sported? This was a good example of how you want to be prepared for things even if they don't frequently happen. I have fire insurance even though I've never had a house fire. Not because I think I will definitely need it, but because the cost of preventing a bigger fallout is worth it to me. YAGNI is not the be-all-end-all argument in the way you're using it.
    – Flater
    Feb 29 at 4:54

I think what confuses you about EF is the database context. It allows you to query objects like a Repository and save changes in persistence like a Unit of Work.

You have a lot of work done with EF database context. All you have to do is segregate the responsibilities by creating specific repositories and a unit of work that share the database context and pesists all changes in presistence with a single save call.

Check this link about create Repositories and UoW in EF. It is clear and easy to understand.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.