How to use Store Procedure and Complex types using Repository Pattern in EF?

Question

How can we use store procedures, and complex types while dealing with Repository pattern in Entity Framework?Could anybody please give a simple example.

Also in what situation should we actually go for an Repository pattern?

Thanks in advance

Answer 1

I think you have missed a point as to why people implement repository pattern when EF already implements repository pattern through ObjectSet/DbSet?

Popular answer would be because many tutorials advice you to use it without justifying reasons. There are valid reasons not to use Repository layer over ObjectSet/DbSet. However I will point out some reasons as to why it it preferable.

Default filters There are many situations in real life applications where you need a default filter. For example discontinued products are not sold. If you expose the Products ObjectSet/DbSet directly there will be problems if someone forgot to apply the default filter. It also avoids the duplication of the logic. You can also modify the default filter later without breaking issues.

public IQueriable<Product> GetAll()
{
    return context.Products.Where(p => !p.IsDiscontinued);
}

Soft Deletes Many applications use soft deletes where you keep a column such as IsDeleted without actually removing the row. Now the ObjectSet/DbSet has a Delete method but once you call this method it will assign null values to the nullable FK properties. You may not want this.

public void Delete(Product product)
{
    // can apply any other logic here
    product.IsDeleted = true;
}

Read Only Entities There are many situation where some other application is in charge of creating, deleting and updating entities and your application is only displaying the entity. But the ObjectSet/DbSet exposes unsupported functionality in this case. Another benifit in this case would be to use NoTracking option to reduce the entity materialization time.

Switch Data Access without exposing implementation There are occasions where LINQ is not sufficient. Here you can use raw SQL or SPs. Having a repository will avoid exposing different methods of querying/updating when the functionality exposed by EF is not sufficient.

Working with Existing Databases When you do not have the luxury of creating the database that EF is capable of handling. Existing table may have Sql Variant, XML columns. Duplication of entries to another tables and countless other cases that you need to handle to keep the integrity of the database.

These techniques may not be bullet proof but will come in handy if situation demands it. What I would suggest is without jumping straight in to repositories you better think about does adding another abstraction layer necessary to implement the required functionalities.