dependency injection - Entity Framework 4 and Repository Pattern -

could explain benefits of using pattern?

i mean isn't ef repository in sense already? can't query container , return objects?

i see lot of talk poco's, automapper, dependency injection, service layers, ioc. mixing bunch of stuff together, or relate?

can explain me?

also, how fit mvc.net, viewmodels vs datamodels?

thanks, sam

there bunch of random question's there, i'll give bunch of random answers:

• a repository defined (by martin fowler) "mediates between domain , data mapping layers using collection-like interface accessing domain objects"
• ef orm, data mapping layer
• yes, can query ef container , return objects, consumer "knows much" underlying persistence mechanism, when shouldn't know/care - hence repository pattern
• poco's technique used free objects persistence meta data (used default ef code gen). allow poco's double domain models.
• viewmodels used mvc views.
• automapper used translate viewmodels domain models ease.
• service layers provide middle-ground between controllers , repository - used iqueryable<t> repositories, materialize queries concrete sequences (e.g icollection<t>).
• ioc used de-couple dependencies between components, gives good/clean architecture , supreme testability (you can pass through mock repository controllers, unit test them in isolated fashion).

elaboration requested on #3

example controller without repository:

public class productscontroller {    public actionresult getproduct(int productid)    {        product p;         using (var ctx = new mysecretcontextwhichisnowexposed())        {           p = ctx.products.singleordefault(x => x.productid == productid);        }         return view(p);    } } 

problems above:

1. the controller working directly entity framework object context, means web application knows it, , need reference system.data.entity.
2. unit testing virtually impossible. you'll testing against actual database makes integration test , not unit test.
3. the controller has logic of "how retrieve single product", when shouldn't - domain/repository logic.

example controller with repository (and ioc):

public class productscontroller {    private readonly iproductsrepository _repo;     public productscontroller(iproductsrepository repo)    {       _repo = repo;    }     public actionresult getproduct(int productid)    {        product p = _repo.findbyid(productid);        return view(p);    } } 

why above better:

1. controller has no idea ef. no dependency on system.data.entity.
2. controller doesn't know implementation of repository, it's working via interface.
3. controller doesn't supply logic on how retrieve product, id.
4. 2 lines of simple code.
5. unit of testing = piece of cake. pass through mockproductrepository in ctor, , work off (which implemented in-memory list).