8
2.72k
1
0
0
0
9
public interface IRepository<T> where T : class
{
IQueryable<T> GetQuery();
IEnumerable<T> GetAll();
IEnumerable<T> Find(Expression<Func<T, bool>> where);
T Single(Expression<Func<T, bool>> where);
void Delete(T entity);
void Add(T entity);
}
public class BaseRepository<TEntity> : IRepository<TEntity> where TEntity : class
{
readonly IObjectContext _objectContext = null;
readonly IObjectSet<TEntity> _objectSet = null;
public BaseRepository(IObjectContext objectContext)
{
if (objectContext == null)
throw new ArgumentNullException("objectContext");
_objectContext = objectContext;
_objectSet = _objectContext.CreateObjectSet<TEntity>();
}
public IQueryable<TEntity> GetQuery()
{
return _objectSet;
}
public IEnumerable<TEntity> GetAll()
{
return _objectSet.ToList();
}
public IEnumerable<TEntity> Find(Expression<Func<TEntity, bool>> where)
{
return _objectSet.Where(where);
}
public TEntity Single(Expression<Func<TEntity, bool>> where)
{
return _objectSet.SingleOrDefault(where);
}
public void Delete(TEntity entity)
{
_objectSet.DeleteObject(entity);
}
public void Add(TEntity entity)
{
_objectSet.AddObject(entity);
}
}
To get more information about the IObjectContext check this code out:
Keep Entity Framework ObjectContex in a WCF Service OperationContext
twitter
Mark '.net' tag as 'like'
Mark '.net' tag as 'ignore'
Fork
0 Feedback
You must log in before you can give any feedback
0
I really like this base class and I'm using a very similar one myself, but I'm calling it
RepositoryBase<T> ;-).
I'm a bit undecided about the GetQuery method though. While I understand why it is useful, it seems to make the other Get/Find methods unnecessary. The Repository also looses a lot of control over when and how data is being accessed when you
expose the IQueryable. This may not be a problem, but is something to have in mind.
0
What would be the best implementation to get none-tracking entities in order to speed up materialization?
0
The reason of the IQueryable is for those who wants to use it in a subclass.
1
Some points here:
I would avoid having "Add" and "Delete" on an interface or baseclass like that, simply since there might be entities/AR's that dont support add or delete..
I would also avoud having "Find(Expression ..." or IQueryable there. Every real world project I have been in lately have required us to fetch data from multiple data stores, thus I can only use Linq for the properties mapped to the DB and not for properties that are filled from other stores.
I'd rather go for methods like "FindByXyz" since that places the responsibillity to collect the correct data on the repository developer rather than the repository consumer..
Exposing IQueryable via an interface would make it public to the outside and thus give the repository responsibillity of a query provider rather than a dumb bucket of things..
0
The Add and Delete methods are quite necessary to build a proper Repository. According to Fowler, a Repository should be "a collection-like interface" and "Objects can be added to and removed from the Repository".
1
So you would include a Delete method on an "OrderRepository" ? even though the domain rules would specify that Orders may not be deleted (they are cancelled not deleted)
What would you possibly gain by adding such method in that case?
Also note the wording "collection-like"...
0
Well, that's a point. But I would argue that if your domain rules states that something cannot be treated as a simple collection, then the repository pattern is probably not right for that specific case.
0
Reply to: CodingInsomnia I would suggest then, that you create separate interfaces for each CRUD operation. That is IRespositoryAdd, IRepositoryUpdate, IRepositoryDelete. Leave the "fetch" interfaces in the base.
Then each aggregate respository, such as OrderRepository, can just compose whichever interfaces it wishes to provide:
public class OrderRepositor : IBaseRepository<>, IRepositoryAdd<>, IRepositoryUpdate<>
A "full" repository, would use all interfaces.
0
You must log in before you can post a comment
