Supporting UnitOfWork

[mehdihadeli]

Hi,
Thanks for your good implementation.
I have a suggestion, In my opinion it is better we have a separated UnitOfWork pattern on top of this repository instead of doing SaveChanges inner repository because it is not responsibility of a repository, and it breaks single responsibility.

[TanvirArjel]

@mehdihadeli I am still not sure about whether should I change this or not. But If I do this, then it will be a huge breaking change that will break existing applications.

[Krzysztofz01]

Generic Repositories are often considered an anti-pattern (in the Entity Framework world), thats beacuse the SaveChanges() is affecting all tracked entities. Maybe this problem can be resolved in such a way as to provide two types of repositories. One standard IRepositry<T> without exposed SaveChanges() placed in IUnitOfWork with the SaveChanges()/Commit() method and the other ITrackedRepository<T> which also includes the option of saving the transaction. This is not a solution to the problem, but it requires you to do something about the problem from the code level. I can post an implementation of my proposal.

[TanvirArjel]

@Krzysztofz01

This is not a solution to the problem, but it requires you to do something about the problem from the code level. I can post an implementation of my proposal.

Of course, you can!

[HybridSolutions]

Personally, don't like the idea of UoW while using EF. It's an unnecessary level of abstraction and it will make the library heavier and complicated. Been using only the Repository pattern and transactions without any issue so far, although I understand there might be valid usages for it. I like this library because of it's simplicity.

[TanvirArjel]

Please share your thoughts in : #25