actually I have implemented my repositories and unitofwork this way and I also found an informative answer by Mr.qujck regarding my question which helped me to a large extent but the only problem I have is that in that topic according to his answer I have no idea how and where should I implement my CRUD operations.I also have this question which has remained unanswered .I would be grateful if someone can help me.

- 1
- 1

- 71
- 1
- 4
-
1The `IRepository<>` in the question you link to is a very poor example of the Repository pattern and I fully understand your confusion: [here](http://www.codeproject.com/Articles/526874/Repositorypluspattern-cplusdoneplusright) is a much better example. In the example the `DbContext` is injected into all the Repositories and the UnitOfWork and therefore the UnitOfWork does not care or need to know to about the Repositories. – qujck Aug 25 '15 at 12:09
-
Thanks for your attention Mr.qujck I read the whole article . It was good , but it raised some questions for me . I've gotten a bit confused ! 1.should generic repositories be avoided or not ? is using them justified when we just want to do crud operations ? using them is a matter of taste or there is a strong reason for not using or using them ? seems there is a great deal of debate among people regarding using or not using them. – Khosro.Pakmanesh Aug 25 '15 at 18:16
-
2.the article you referenced to gave me a good understanding about the whole idea but it seems it is not complete and also there is not any source code along the article to summarize the article. I would be obliged if you provide me with a reference or resource that implements these ideas completely. – Khosro.Pakmanesh Aug 25 '15 at 18:16
-
See [here](http://stackoverflow.com/q/14110890/1515209) for some useful information. Personally I have moved away from EntityFramework due to myriad issues trying to performance tune the application. I now have `IUnitOfWork` and `IRepository<>` abstractions wrapping [Dapper](https://github.com/StackExchange/dapper-dot-net) but do not have any useful articles I can point you towards sorry. – qujck Aug 26 '15 at 07:54
-
Thanks dear Mr. qujck – Khosro.Pakmanesh Aug 27 '15 at 04:14
2 Answers
EntityFramework
already provides you with all the functionality regarding CRUD operations, and generally speaking, you don't need to test EntityFramework, because we just assume that it works. The way it is shown in that website, is that you create a higher abstraction layer than simple CRUD operations, build it on top of EF, and call it Repository
(Data access layer). So in this case, you only need to make sure that you DAL (aka Repository in this case) is decoupled. The only thing repository is coupled to is EntityFramework's DbContext, which, is not realy decouplable from, so the lowest level of abstraction that you realy need to test and decouple upwards is your Repository
class.

- 656
- 5
- 16
-
actually i want to create my MVC application based on DDD principles,so I need to wrap entityframework dbcontext methods with my own crud operations in my repository in order to prevent users from having direct access to the mentioned methods to apply my invariants . If you look at Mr.qujck answer in the second link the only thing that has missed is implementing crud operations. I hope you get my point. – Khosro.Pakmanesh Aug 25 '15 at 10:21
The way the Unit Of Work pattern is being employed in that example does not truly represent how a UoW should behave. The repositories should have knowledge of the UoW, but the UoW should not have any reference to your repositories. The UoW should only know about your context. In my example below, you remove the repository dependencies from the UoW. For testing, you could implement a fake DbContext if you really needed to, bu that may be overkill.
Another suggestion I have is to add one further abstraction to your repositories and create a Service layer. This will act as your Business layer and these would be injected into your MVC controllers. This way, if you work with DTOs or view models, you can map betwen entities and DTO in that layer so the application will never really expose your underlying DAL.
public interface IUnitOfWork : IDisposable
{
/// <summary>
/// Flushes content of unit of work to the underlying data storage.
/// Causes unsaved entities to be written to the data storage.
/// </summary>
void Flush();
/// <summary>
/// Begins the transaction.
/// </summary>
ITransaction BeginTransaction();
/// <summary>
/// Ends transaction.
/// Note: suggested pattern to manage a transaction is via *using* construct.
/// You should set input param to null after calling the method.
/// </summary>
/// <example>
/// using ( var tnx = uow.BeginTransaction() ) { /* do some work */ }
/// </example>
/// See also <seealso cref="ITransaction"/> interface for more details.
void EndTransaction(ITransaction transaction);
/// <summary>
/// Inserts entity to the storage.
/// </summary>
void Create<TEntity>(TEntity entity) where TEntity : class;
/// <summary>
/// Updates entity in the storage.
/// </summary>
void Update<TEntity>(TEntity entity) where TEntity : class;
/// <summary>
/// Updates entity in the storage.
/// </summary>
void Merge<TEntity>(TEntity original, TEntity current) where TEntity : class;
/// <summary>
/// Deletes entity in the storage.
/// </summary>
void Delete<TEntity>(TEntity entity) where TEntity : class;
}
public interface IRepository<TEntity> where TEntity: class
{
void Create(TEntity entity);
TEntity GetById(object id);
IEnumerable<TEntity> Get(Expression<Func<TEntity, bool>> criteria);
IEnumerable<TEntity> GetAll();
void Delete(object id);
void Delete(TEntity entity);
void Update(TEntity entity);
void Merge(TEntity original, TEntity current);
IUnitOfwork UnitOfWork { get; }
}
public class EntityFrameworkUnitOfWork: DbContext, IUnitOfwork
{
public virtual void Flush()
{
//The DbContext Save Changes method..
SaveChanges();
}
public virtual void Create<TEntity>(TEntity entity) where TEntity : class
{
base.Set<TEntity>().Add(entity);
}
..other method implementations...
}
public class Repository<TEntity> : IRepository<TEntity> where TEntity : class
{
private readonly IUnitOfWork _unitOfWork;
public Repository(IUnitOfWork unitOfWork)
{
_unitOfWork = unitOfWork;
}
...other method implementations...
}

- 4,225
- 5
- 63
- 117
-
Thanks for your reply.I thought the resource that I introduced previously should be a good reference to learn about UOW and Repository but I really don't know why they share wrong information. However,regarding both of your approaches could u please provide me with a comprehensive resource to help me learn these patterns in a right way. – Khosro.Pakmanesh Aug 25 '15 at 16:52