Develop Reference

Repository pattern connection string

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.

C# repository pattern dbcontext error

I'm trying to make something with repository pattern i made 3 layers winUI , dll and repository all of them has referenced entity framework but my base repository doesn't work here is code below
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using KuzeyYeli.ORM.Models;
namespace KuzeyYeli.Repository
{
public class RepositoryBase<T> where T:class
{
private static NORTHWNDContext context;
//singelton pattern
public NORTHWNDContext Context
{
get {
if (context==null)
context=new NORTHWNDContext();
return context;
}
set { context = value;}
}
public IList<T> Listele()
{
return Context.Set<T>.ToList();
}
}
}
Set gives me error like " does not contain definition for 'set' and no extension " and by the way when i write "Context." i cant see the classes made by EF i really neeed to know please help

The whole point of having a repository pattern is to decouple the various layers in your application in addition to making it easier to unit test your application.
The proper way to implement the repository pattern is to have an interface that defines four basic methods...
public interface IEntity
{
string Id { get; set; }
}
public interface IRepository<T> where T : IEntity
{
void Add(T entity);
void Remove(T entity);
void Create(T entity);
T Find(string id);
}
Now you can implement this interface for any of your entities, let's imagine you're creating a blog, a blog would contain posts right?
So, create a PostsRepository...
public class Post : IEntity
{
public Post()
{
this.Id = Guid.NewGuid().ToString();
}
public string Id { get; set;}
}
public class PostsRepository : IRepository<Post>
{
public void Add(Post entity);
/// etc
}
That's how it's supposed to be implemented, though the above example does not take into consideration that the data access logic is composed using Entity Framework.
Now that we know what the Repository Pattern is, let's move on to integrating Entity Framework...
In the PostsRepository class, you would have a property that could reference your Entity Framework DbContext. Remember that PostsRepository is a concrete implementation which will be used for any other class that is dependent on IRepository.
So why bother, seems like a lot of trouble for little gain, but you'd be wrong...
Imagine that you're attempting to validate content within a post that is submitted to a website... How would isolate the validation logic whilst avoiding making any calls to the database?
You could either create hand rolled mock objects that implement IRepository that doesn't reference EntityFramework as the data source (this is a long winded approach)... or you could simply use frameworks available out there already such as Moq, which you use to create a fake implementation of IRepository.
So, in short what you need to start studying is:
Dependency Inversion
Repository Pattern
Decorator Pattern
N-Tier architecture
Onion architecture
All of those will have a major impact on how maintainable your application will be once the code base has grown. You don't need to be an expert, that will come through making mistakes and biting a few bullets here and there... but having a general understanding of those will make tremendous difference even in the short term.

C# Generic Interfaces whitelist candidates filtering

I am very much new to Generics and found it very helpful in case Repository creation.
My question must be very basic level.
Suppose, I have declared a Generic interface something like
public interface IEFRepository<T> where T : class
{
int Count { get; }
bool Contains(T entity);
IQueryable<T> GetAll();
IQueryable<T> GetAll(string includeEntities);
IQueryable<T> FindBy(Expression<Func<T, bool>> predicate, string includeEntities = "");
T Add(T entity);
T GetById(int id);
void Delete(T entity);
void Update(T entity);
int ExecuteSQL(string commandText);
void Delete(int id);
}
Now, I can pass any class that implements this contract.
But I want to restrict it from being inherited by Only white list Classes that is configured in my Config file
eg. "Person | Department | Employee" are allowed.

You can use constrains on Type Parameters, for example, restricting it to just classes that inherits from another one.
public interface IEFRepository<T> where T : MyBaseClass
http://msdn.microsoft.com/en-us/library/d5x73970.aspx

You should restrict your T classes belonging to a specific type, lets say an interface IEntity. Then your declaration would be:
public interface IEFRepository<T> where T : IEntity
Then you would declare your respective classes (Person, Department etc) to implement IEntity interface. This is far better solution because it gives you a strongly typed structure and protects you from runtime errors. Reading from app.config could easily lead you to runtime errors. Since you are implementing the repository pattern, perhaps you should read this very informative post regarding the repository and the unit of work patterns implemented using entity framework.
If you want to change the classes being entities in a dynamic way (without having to recompile your code) you could use reflection API to do so. This is far more complicated and I would not suggest it but you know your project's requirements. By using reflection, you would be able to read the configuration file and instantiate the respective classes directly, without needing them to implement interfaces or declaring their relation with the repositories in your code. Interfaces and inheritance give you compile time consistency, while configuration options give you runtime choices. I would prefer the first. You choose...
Hope I helped!

Generic Repository Pattern have repetition of code so what will be benefit?

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".

Repository testing minimizing repetition

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.