如何在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.

Answer 2

repository patterns are important to decouple your data storage mechanism from your application. By doing this you make it a lot easier to unit test or replace the data structure at a later date. Read my blogpost around how/why I do this here: http://blog.staticvoid.co.nz/2011/10/staticvoid-repository-pattern-nuget.html

Personally I never use stored procedures any more as I don't really see a need for them in most circumstances, however to implement this with my repository pattern i would recommend that you create a new RepositoryDataSource to map to your stored procedure and then call the stored proceedure via EF or old school SQL. I would recommend throwing an exception of some kind on update or save.

==EDIT (In response to the question 'why 2 layers')==

The reason I've chosen to go for two layers is because in my mind a repository is both to do with how you get the data (the data source layer) and how you present the layer (in my implementation, perhaps badly named repository). By splitting the implementation in half the how can remain the same regardless of the what. conversely if you want to change the how you can do so while remaining only loosely coupled to the what.

For example you may want to swap your EF data source for an in memory version. This shouldn't necessarily change how the data is presented to the application.

On the other side you may want to cache your data or prehaps log some information on the performance of writes to the datastore. Why should it matter what actual storage mechanism is used under the covers?

Personally I've found the split in this particular place to make the solution much more flexible.