Repository Pattern: How to implement a basic Repository including a predicate in C#?

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, espec开发者_运维百科ially how to implement the predicate in a repository.

---

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.

---

The repository interface you've presented is a very easy-to-use CRUD interface that can work well in many types of applications. In general, I'd rather not have paging and sorting parameters or options on my repository, instead I'd rather return an IQueryable and let callers compose those types of operations into the query (as long as you are IQueryable, a technology like EF or nHibernate can translate those operators into SQL - if you fall back to IList or IEnumerable it's all in memory operations).

Although I avoid paging and sorting I might have more specific operations on a repository to shield business logic from some details. For example, I might extend IEmployeeRepository from IRepository and add a GetManagers method, or something similar to hide the Where expression needed in the query. It all depends on the application and complexity level.

One important note on this sentence in your post:

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.

Make sure you are using a single data context/object context inside each unit of work, because a context is essentially the underlying unit of work. If you are using multiple contexts in the same logic transaction then you'd effectively have multiple units of work.

I have a couple sample implementations in this project: http://odetocode.com/downloads/employeetimecards.zip

The code might make more sense if you read this accompanying article: http://msdn.microsoft.com/en-us/library/ff714955.aspx

Hope that helps,