concrete sense of IRepository<T> vs Repository if I do not do unit tests with mocks

Question

I have this:

public interface IRepository<T> where T : class
{
    void Delete(T entity);
    void Add(T entity);
    void Attach(T entity);
    void Detach(T entity);
    void SaveChanges();
}

now for every of my Entity I make concrete classes implementing the generic IRepository =>

public class SchoolclassRepository : IRepository<Schoolclass>
{
    public void Delete(Schoolclass entity)
    {
        throw new NotImplementedException();
    }

    public void Add(Schoolclass entity)
    {
        throw new NotImplementedException();
    }

    public void Attach(Schoolclass entity)
    {
        throw new NotImplementedException();
    }

    public void Detach(Schoolclass entity)
    {
        throw new NotImplementedException();
    }

    public void SaveChanges()
    {
        throw new NotImplementedException();
    }
}

In my ViewModel`s constructor (mvvm pattern) I do this =>

IRepository<Schoolclass> repo = new SchoolclassRepository();

What advantage is there with IRepository when I have anyway to write the code for my CRUD operations in every entities class?

In Customer, Product, Pupil whatever class I implement the IRepository<Product> , IRepository<Customer> , IRepository<Pupil> etc... and I implement the methods of the interface.

Why could I not say =>

SchoolclassRepository repo = new SchoolclassRepository(); ??? 

I do not care for having the possibility to write unit tests for a small app.

Answer 1

The repository pattern is based around IoC and dependency injection patterns, unit test just happen to need IoC and dependency injection to make things easier to test. It was not originally intended to be another way to write the data access layer, although many post and implement it as such. For small apps it depends on how much effort you want to put in.

Typically the implemenation SchoolclassRepository will be in a separate namespace from the IRepository interfaces so you can support multiple implementations. (Not a rule)

You can set your ViewModel s constructor (mvvm pattern) to take a parameter for the repository interface IRepository<Schoolclass>. Now your ViewModel s constructor (mvvm pattern) to take a parameter for the repository interface IRepository<Schoolclass>. Now your ViewModel s constructor is based on the interface and not the implementation.

private IRepository<Schoolclass> _repository
public ViewModel(IRepository<Schoolclass> Repository) 
{ this._repository = Repository; }

Why do the above ....

The pattern also makes future changes easier to make.

If your implementation of SchoolclassRepository() used ADO.NET (sqlconnections, sqlcommands...) to access data, you can later build another SchoolclassRepository() that uses NHibernate, Entity Framework or some other data access method. Now all you have to do is change your consumers to use the targetted implementation and inject them into the ViewModel.

Repository repository = new ADONET.SchoolclassRepository(); 
or
Repository repository = new EntityFramework.SchoolclassRepository(); 
ViewModel viewmodel = new ViewModel(repository);

This is just q quick view into the uses, I would recommend further study into the repository pattern and how to make it work for you. You are obviously interested in it which it good.