Question

I am new to repositories. I just read about implementing predicates and a Unit of Work (Fowler). I have seen repository interfaces like the following:

public interface IRepository<ET> {
    ET        Add( ET entity);
    ET        Remove( int id);
    ET        Get( int id);
    IList<ET> Get(Expression<Func<T, bool>> predicate);
}

Of course the Unit of Work would inject a data context (Microsoft fan) to the new repository, where the Unit of Work would have a .Save() method, calling Save on all data contexts.

There’s no Edit method, so I assume you can modify any Entity that pops out of the Repository then call save changes on the Unit of Work.

Is this correct? Leaky? What am I missing? Do methods of OrderBy need not ever be in a Repository? Should Paging (.Skip().Take()) somehow be implemented in the predicate?

Links to example code out there would be fantastic, especially how to implement the predicate in a repository.

Answer 1

if you are referring Entity Framework
i would you suggest you read this: Link

Update:

I am not a expert in repository pattern, however i do using it in my project now. a part form performance, following is the benefits that i find from this design pattern:

1, Simplify CRUD operation implementations for all entities.
with one interface:

public interface IDataRepository<T> where T : class

then you will be able to replicate others very easily and fast

public class EntityOneRepository : IDataRepository<EntityOne>
public class EntityTwoRepository : IDataRepository<EntityTwo>

2, Keeps my code dry.
some entities may have their own method for data manipulation. (i.e. store procedure)
you can extend it easily without touching other repositories.

public interface IDonationRepository : IDataRepository<Donation>
{
//method one
//method two
//....
}

for the Paging, it can be either done by Skip() and take(), or you can define your own SP in database then call it via EF4. in that case you will benefit from database sp caching as well.

Some time, keeping the code clean and logically readable is also important for a better app structure.