Advice on the repository pattern with MVC3 & EF

I had a discussion with another developer regarding the repostory pattern with mvc3 and the EF that has gotten me sightly confused.

I am not sure the best practice to follow using the repository pattern with MVC3 and the EF.

Lets say I have a table called Product containing ProductID & ProductName. I create my new EF model. I also create a basic model ProductModel

public int ProductID{get;set:}
public string ProductName{get;set}

Should my controller know anything about my entity created by the EF? or am I meant to be doing all my talking to the EF inside my repository?

e.g. A basic post

[HttpPost]
public ActionResult Product(ProductModel model)

Then in my controller, I pass the model to my repository to take care of the insert or should my controller be bound to directly to my EF Product Model and then pass that to my repository to take care of the insert.

I thought the idea of the using the repository is that lets say in 12 months time if I wa开发者_如何学Gonted to stripe out the entity framework and use something else I would only need to update my repository and wouldn't have to touch any of my controllers.

What is the best practice?

If you wan to stripe out the entity framework after some time withoud changing Controller you need to use repository pattern to separate persistence logic from UI.

And additionally don't use model classes as view models for the MVC layer.You can use separated view models for UI logic and Use something like AutoMapper ( http://automapper.codeplex.com/ ) to map with model classes .

Your last paragraph sums it up perfectly.

You'd want to use interface-driven development, so that your Controller's deal with a IProductRepository.

Use dependency injection to inject a concrete Entity Framework repository into the Controller.

As @Jayantha mentions, your [HttpPost] action should accept a ViewModel, not the EF model.

Then use AutoMapper to map between the ViewModel and the EF model.

The repository will wrap EF logic in one place (Save, Delete, Update, etc), so your Controller stays simple and dumb.

Keep your interface as simple and as thin as possible, then if/when you switch over to the new implementation, as long as the new one can conform to the interface specification, then your Controller's need not change, only the dependency injection configuration.

I prefer use Dev Magic Fake, with Dev Magic Fake you don't need to use EF or consider anything, you just need to add reference to Dev Magic Fake assembly and start using the magic methods

[HttpPost]
public ActionResult Product(ProductModel model)
{
   var repoistory = new FakeRepository<ProductModel>();
   repoistory.Save(ProductModel);

For more information see Dev Magic Fake on CodePlex

http://devmagicfake.codeplex.com

Thanks M.Radwan