I am building a generic Repository for a WinForms kinda small app like this:
public interface IRepository<T> where T : class
{
IEnumerable<T> GetAll();
IEnumerable<T> Find(Expression<Func<T, bool>> query);
T GetByID(int id);
void Add(T item);
void Update(T item);
void Delete(T item);
}
I know that many recommend against using the repository pattern, but in this case saves a lot of code, since all the POCO's will be very similar and use all the methods declared in the interface.
This will be implemented using ServiceStack.OrmLite.
I don't want to use ConfigurationManager to get the connection string. What would be a good way to achieve this? I thought about using a BaseRepository class to initialize a static connection string, but I am not sure how to implement this.
Any suggestions?
A BaseRepository class woudl be an abstract class that implements the methods in IRepostiory<T> abstractly:
public class BaseRepository<T> : IRespository<T> where T : class
{
protected readonly string ConnectionString = "your connection string here"; /*could event be static?*/
public abstract IEnumerable<T> GetAll();
/*....*/
}
I've not used OrmLite, but it looks like you could probably implement most of the methods in the BaseRepository class. Any decent DI container could then use this, rather than having to have a separate repository class for each entity.
However, as the Repository pattern is typically used with the Unit of Work pattern, you might want to consider how this all communicates.
One final note: I'd warn against GetAll as IEnumerable - apart from maybe lookup tables will only ever have a small number of rows. Once you start to have any volume of data, you'll need to retrieve it in chunks - loading hundreds of thousands (or more?) records in one go will be pretty slow.
Related
For example we have simple interface for generic repository:
public interface IRepository<T> where T: class, IAgregateRoot
{
void Insert(T agregateRoot);
void Delete(T agregateRoot);
IQueryable<T> GetAll();
IQueryable<T> SearchFor(Expression<Func<T, bool>> predicate);
T GetById(Guid id);
}
Its necessary to implement this using JSON.NET. What is the best way to do this? Should we use some data types from .NET to store collection in memory, e.g. System.Data.Linq.Table?
I enjoy the setup of this guys repository pattern. Though I feel it is getting a bit heavy now. You could take the parts you like and strip out the rest like I have done. Mainly look at the Repository implementation.
Link
I have implemented IRepository interface for multiple domains but I don't know how to call specific method.
Below is the code :
public interface IRepository<T> where T : class
{
IEnumerable<T> GetAll();
void Add(T entity);
void Update(T entity);
}
public interface IProjectRepository : IRepository<ProjectType>, IRepository<Project>, IRepository<ProjectDetail>
{
}
public class ProjectRepository : IProjectRepository
{
// implemenation
}
Now, When I create object of ProjectRepository class it shows all methods of interface but only expecting projecttype parameter.
I don't know, is it correct way of implementation? or Is there another way to implement similar thing?
Generic repository IRepository<T> is not a good solution IMO, take a look at http://www.sapiensworks.com/blog/post/2012/03/05/The-Generic-Repository-Is-An-Anti-Pattern.aspx
I think it's better to specify each repository separately without generic paramter and common methods (are you sure you will always need Add, Update, GetAll in all of your repositories?)
I think it can be better to create Generic repository with Unit of Work pattern.
Take a look at
http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application
this is good tutorial about implementation Generic repository with Unit of Work
And at
http://contosontiermvc.codeplex.com/SourceControl/changeset/view/13936#ContosoUniveristy/ContosoUniveristy/Controllers/CourseController.cs
.this is code example
I am understanding repository pattern in c#. I am confused when i study about generic repository pattern. There is lot of repetition in it. i have some question about this pattern.
I am using Entity Framework code first approach and i have two model classes
Student
Teachers
How many generic interface i will use for example if i have one
generic interface
public interface IRepository<TEntity>
{
IQueryable<TEntity> FindAll(Expression<Func<TEntity, bool>> where = null);
TEntity FindOne(Expression<Func<TEntity, bool>> where = null);
}
So this interface can be use in both model classes.
if Student class have more methods where i can define these methods? for example
public class StudentRepo<TEntity> : IRepository<TEntity> where TEntity : class
{
public virtual IQueryable<TEntity> FindAll(Expression<Func<TEntity, bool>> where = null)
{
return null != where ? Context.Set<TEntity>().Where(where) : Context.Set<TEntity>();
}
public virtual TEntity FindOne(Expression<Func<TEntity, bool>> where = null)
{
return FindAll(where).FirstOrDefault();
}
public void update()
{
}
public int FindId()
{
}
}
So i have added two new methods update() and FindId() in StudentRepo where can I define these methods?
If I want to add these two methods in IRepository then I have to call these methods for Teacher class. what will be benefit of it?
Is this better approach if i create separate interface for both classes? like IStudent and ITeacher so i can define those methods which i want to use and unnecessary methods will not be in use.
Kindly guide me i am so confused.
You can have one implementation for the IRepository that you have, something like:
public class GenericRepository<TEntity> : IRepository<TEntity> where TEntity : class
{
public virtual IEnumerable<TEntity> FindAll(Expression<Func<TEntity, bool>> where = null)
{
// implementation ...
}
public virtual TEntity FindOne(Expression<Func<TEntity, bool>> where = null)
{
// implementation
}
public void Update(TEntity entity)
{
// update your entity ...
}
// etc...
}
Then have your own repository inheriting from it:
public class StudentRepository : GenericRepository<Student>
{
// here you get all the goodies + you can add your own stuff
}
And:
public class TeacherRepository : GenericRepository<Teacher>
{
// here you get the same goodies, you don't need to re-implement them
}
This way you don't have to re-implement all the methods defined in the generic repository, you can however add your own more complex methods.
Generic repositories are worthless. They just do the same thing as entity framework and most of the implementations out there expose IQueryable<T>.
So why is that so bad?
The repository pattern is used to create an abstraction between the data source and your code. That abstraction is created to reduce complexity and to reduce coupling between those tiers.
A generic repository might seem to be a good choice at first, but as every entity (root aggregate) have their own unique features you will always have to write custom queries to fetch them.
To solve that, most generic implementations expose IQueryable<T>. That is a bad thing since there is no 100% complete Linq to Sql provider (a set of classes which translates the LINQ statement to a SQL statement). Every provider has to resort to custom commands to support eager/lazy loading, support for IN sql clause etc.
You always have to be aware of those customizations every time you use the repository through IQueryable<T>.
Hence you still have to know about how Entity Framework works. You could therefore use EF directly instead of using a generic repository.
If you truly want to use the repository pattern, please design your code first with all your classes. And THEN create the database. That is, fit the DB after your code and not vice versa. And make sure that your repository is 100% complete abstraction (google for instance persistance ignorance)
I think that the Generic Repository idea is trying to generalize too much, seperate interfaces are better in my opinion as they provide a more meaningful contract, this blog explains it very good, and offers to use the generic repository "behind the scenes".
A have an application with a typical scenario data access layer (DAL):
Data context created with Entity Framework (EF).
Using entities generated by EF used as general DTOs for the whole application.
DAL contains different repositories that extend a RepositoryBase abstract class, which implements basic CRUD operations; the specific repositories have only specific methods for their entity types. Repositories for entities that can be soft deleted extend a SoftDeleteRepositoryBase instead, that itself extends RepositoryBase.
To give some context, here are some classes/interfaces.
Generic repository interface:
public interface IRepository<T> : IDisposable where T : class
{
void Add(T entity);
void Update(T entity);
void Obliterate(T entity);
void Obliterate(Expression<Func<T, bool>> where);
T GetById(long id);
T GetById(string id);
IQueryable<T> GetAll();
IQueryable<T> GetMany(Expression<Func<T, bool>> where);
T GetSingle(Expression<Func<T, bool>> where);
void SaveChanges();
}
Repository base:
public abstract class RepositoryBase<T> : IRepository<T> where T : class
{
...
}
A repository for the Foo entity:
public class FooRepository : RepositoryBase<File>, IFooRepository
{
// Specific methods here
...
}
How should I test the repositories? Right now I have a test class for each repository, with test methods that are very similar in all of them, as they are mostly testing generic methods from the RepositoryBase. It's obvious that I need tests for the specific methods, but for the global generic ones should I keep testing them against each different entity? I don't know if it's wise to assume that if insertion, for instance, works for Foo entities it will also work for others; however testing for each has an added overhead in terms of test creation and maintenance. Can you recommend any best practice around this?
(By the way, these are integration tests)
Thanks
I don't know if it's wise to assume that if insertion, for instance,
works for Foo entities it will also work for others
No, you can't assume this. What if some entity do not have correct mapping? What if you forgot to define DbSet<Bar> on your DbContext? If you want to be completely sure, you should test all methods of all concrete repositories.
however testing for each has an added overhead in terms of test
creation and maintenance
Correct. That's why instead of writing integration tests for repositories only, write acceptance tests for your application. You will exercise whole stack and concrete repositories will be involved.
What is a IRepository? Why is it used, brief and simple examples won't hurt.
MVC promotes separation of concerns, but that doesn't stop at the M V C level.
Data Access is a concern in itself. It should be done in the M bit of MVC, ie the model. How you structure your model is up to you, but people usually follow tried and tested patterns (why reinvent the wheel?). The Repository Pattern is the current standard. Don't expect a simple formula, however, because the variations are as many as there are developers, almost.
IRepository is just an interface that you create (it is not part of MVC or ASP.NET or .NET). It allows you to "decouple" your repositories from real implementations. Decoupling is good because it means your code...:
Your code is much more reusable. This is just plain good.
Your code can use Inversion of Control (or Dependency Injection). This is good to keep your concerns well separated. It is especially good because this allows Unit Testing...
Your code can be Unit Tested. This is especially good in large projects with complex algorithms. It is good everywhere because it increases your understanding of the technologies you are working with and the domains you are trying to model in software.
Your code becomes built around best practices, following a common pattern. This is good because it makes maintenance much easier.
So, having sold you decoupling, the answer to your question is that IRepository is an interface that you create and that you make your Repositories inherit from. It gives you a reliable class hierarchy to work with.
I generally use a generic IRepository:
IRepository
Where TEntity is, well, an entity. The code I use is:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Wingspan.Web.Mvc
{
public interface IRepository<TEntity> where TEntity : class
{
List<TEntity> FetchAll();
IQueryable<TEntity> Query {get;}
void Add(TEntity entity);
void Delete(TEntity entity);
void Save();
}
}
A concrete implementation of this interface would be:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Linq;
using Wingspan.Web.Mvc;
namespace ES.eLearning.Domain
{
public class SqlRepository<T> : IRepository<T> where T : class
{
DataContext db;
public SqlRepository(DataContext db)
{
this.db = db;
}
#region IRepository<T> Members
public IQueryable<T> Query
{
get { return db.GetTable<T>(); }
}
public List<T> FetchAll()
{
return Query.ToList();
}
public void Add(T entity)
{
db.GetTable<T>().InsertOnSubmit(entity);
}
public void Delete(T entity)
{
db.GetTable<T>().DeleteOnSubmit(entity);
}
public void Save()
{
db.SubmitChanges();
}
#endregion
}
}
This allows me to write:
SqlRepository<UserCourse> UserCoursesRepository = new SqlRepository<UserCourse>(db);
Where db is a DataContext instance injected into, say, a Service.
With UserCoursesRepository I can now write methods in my Service class like:
public void DeleteUserCourse(int courseId)
{
var uc = (UserCoursesRepository.Query.Where(x => x.IdUser == UserId && x.IdCourse == courseId)).Single();
UserCoursesRepository.Delete(uc);
UserCoursesRepository.Save();
}
And now in my controllers, I can just write:
MyService.DeleteUserCourse(5);
MyService.Save();
With this pattern the development of your app becomes more of an assembly line that leads up to a VERY simple controller. Every piece of the assembly line can be tested independently of everything else, so bugs are nipped in the bud.
If this is a long, unwieldy answer it is because the real answer is:
Buy Steven Sanderson's book Pro ASP.NET MVC 2 Framework and learn to think in MVC.
An IRepository is an interface you specify when you want to implement the Repository Pattern. As #Brian Ball stated, it's not part of .NET it is an interface that you create.
Developers using the Repository Pattern widely recommend the use of an interface for the implementation. For example, in the application I am developing right now, I have 5 repositories. 4 specific and 1 generic. Each one inherits from an IRepository which ensures I will not have issues down the road with differences in implementations.
As far as code examples, I'll try:
interface IRepository<T> where T : class {
IQueryable<T> Select();
}
Implemented as a generic repository:
public class Repository<T> : IRepository<T> where T : class {
public IQueryable<T> Select() {
return this.ObjectContext.CreateObjectSet<T>();
}
}
Implemented as a specialized repository:
public class EmployeeRepository : IRepository<Employee> {
public IQueryable<Employee> Select() {
return this.ObjectContext.Employees;
}
}
Both the Repository<T> and EmployeeRepository implement IRepository, however they go about performing the querying slightly differently. The generic repository has to create an object set of T before it can try to do anything.
Keep in mind that Repository<T> is supposed to be locked to the interface, where as EmployeeRepository can implement more specialized methods to accomplish more complex logic.
I hope this helps you a little.
IRepository is not a defined type in the .Net framework. Usually when you see an interface named that, the program uses the Repository Pattern ( https://web.archive.org/web/20110503184234/http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/10/08/the-repository-pattern.aspx ). Generally when people use this pattern, they will create an interface that all the repositories adhere to. There are many benefits to doing this. Some of the benefits are code de-copupling, and unit testing.
It is also common for this to be done so it can be taken advantage of with IoC ( http://en.wikipedia.org/wiki/Inversion_of_control ).
A repository is an abstraction which represents any underlying and arbitrary data store as if it were an in memory collection of objects.
This definition is morphed into a more practical form due to common practices and system limitations as a collection of objects in memory which represent some underlying and arbitrary data store, possibly a disconnected one. Under the hood the repository may be linked to a database, a flat file, an in-memory collection of objects, or whatever else you may imagine. The user of a repository doesn't care.
So an IRepository is the interface contract which defines how Api code wishes client code to interact with the repository. This often includes add, update, delete, and get contracts as for example, this very common example of a repository contract:
public interface IRepository<TEntity> where TEntity : class
{
List<TEntity> GetAll();
void Add(TEntity entity);
void Delete(TEntity entity);
void Save();
}
But I prefer to use a different interface for a few reasons.
First, you typically wont be using a repository by itself, you will probably be using it with a unit of work pattern, so the repository shouldn't have a Save() method. It might have an Update(T entity) method - but why? The object which you receive from the repository will automatically be updatable/updated just like any other object you would receive from any kind of collection of objects because you have retrieved references to the objects themselves. (For example: if your TEntity is a Person object, and you get person "Chuck", and you change his last name from "Bartowski" to "Carmichael", the repository has presumably already updated said entity. If this seems tenuous in your mind, there is nothing wrong with implementing an Update(T entity) method.)
Second, most repositories should be able to handle disconnected environments. If your solution does not have this requirement, you can still create an interface that handles disconnected scenarios and simply leave it unimplemented. Now you are ready for the future.
At last, our contract makes more sense to the true nature of a repository - a collection of objects in memory which represent some arbitrary data store, possibly a disconnected one.
public interface IRepository<TEntity> where TEntity : class
{
List<TEntity> GetAll();
List<TEntity> Get(Func<TEntity, bool> where);
void Insert(TEntity entity);
void Insert(IEnumerable<TEntity> entities);
void Remove(TEntity entity);
void Remove(IEnumerable<TEntity> entities);
void SyncDisconnected(TEntity entity, bool forDeletion = false);
void SyncDisconnected(IEnumerable<TEntity> entities, bool forDeletion = false);
}
If you define a base class for all of your entities, let's call it DomainObject, and you give it an Id field, then you can do the following:
public interface IRepository<TEntity> where TEntity : DomainObject
{
TEntity GetById(object Id);
List<TEntity> GetAll();
List<TEntity> Get(Func<TEntity, bool> where);
void Insert(TEntity entity);
void Insert(IEnumerable<TEntity> entities);
void Remove(TEntity entity);
void Remove(IEnumerable<TEntity> entities);
void SyncDisconnected(TEntity entity, bool forDeletion = false);
void SyncDisconnected(IEnumerable<TEntity> entities, bool forDeletion = false);
}
If you don't like the optional parameter forDeletion, you can add a method which allow syncing deleted objects as well:
void SyncDisconnectedForDeletion(TEntity entity);
The reason you need to do this is because in most cases, syncing disconnected objects for deletion is incompatible with syncing disconnected objects for addition or modification. (Try it. You will see for yourself the requirements for deletion against a store vary wildly from that of addition or modification). Hence, the interface should define a contract so the implementation can discern between the two.
You can implement this interface against ANY repository of ANY underlying data store, connected or disconnected, including other abstractions to underlying data stores such as Entity Framework.