Repository pattern for database that allows CRUD operations through Interops

Question

The situation we are facing currently is Model Entities and database logic are tightly interweaved together which is making unit tests impossible. So, I decided to go with designing a Repository pattern. The basic structure of storage model what we see through Com interactions Root-Children[each child is another Root]. It's a tree structure. Understanding this, the Repository we designed is RootRepository for CRUD operations on root and ChildRepository internal to RootRepository for CRUD operations for child. We decided Create for only creating an entity but not to persist it but update will either insert only if no entity is key is not found in DB or to update upon found. Read will fetch the entity by key. So while interacting with the Repository API we decided to get entity first using key and if it is null then call Create basic entity(Repository uses factory) and it can be updated if it is required and persisted back to DB using update. No child can be persisted itself since it is an Value object pointing to another entity. To persist child, we have to persist the child referring entity first and later request root Repository to create child object and upon can be added to parent children collection and parent persistence is called so than children will be persisted along with parent.

So, I wonder about the methodology we are following and design pattern is really upto standard. As far as we know this is the only way we can get support for unit testing and test with minimal data mocks. I looked all around on web for getting ideas for building repositories but nothing helped me. Most of my questions here will be addressed in our unit tests but I wonder if there is any design pattern exist already. At this early stage it is easy to migrate to any standard framework if exist and I hope I will get any directions from you guys.

Herrod

Answer 1

Implement the code below, and you'll be able to re-use it across all of your entities.

public interface IRepository<T> where T : class
{
    T Find(params object[] id);
    IQueryable<T> Where(Expression<Func<bool, T>> predicate);
    T Add(T entity);
    T Update(T entity);
    void Delete(T entity);
}

public class Repository<T> where T : class
{
    private DbSet<T> dbSet;
    public Repository(ApplicationContext context)
    {
        this.dbSet = context.Set<T>();
    }

    public T Find(params object[] id) { throw new NotImplementedException(); }
    public IQueryable<T> Where(Expression<Func<bool, T>> predicate) { throw new NotImplementedException();}
    public T Add(T entity){ throw new NotImplementedException();}
    public T Update(T entity){ throw new NotImplementedException();}
    public void Delete(T entity){ throw new NotImplementedException();}
}

Rasping

We are using a similar pattern. But creating a custom Dbset for our need is almost impossible. Since a child referred entity won't have scope without child. E1-child-E2, E2 context can be part of another similar structure but it will not be same object. Ex: Wheel is an entity object but in context, it can be two wheels, right and left wheel to a Car. When we walkthrough tree structure Car->right->Wheel and Car->left->wheel. right and left are children to Car. Left or right doesn't have identity but holds wheel. the basic definition of wheel is same but they will be two different database objs – Herrod

You need to inject that dependency with per request lifecycle – Rasping

So that's the only way to go then and Of course we did exactly as you said. Application Context is per cycle. Thanks for answering. Unless I get other answers I will stick with the idea. – Herrod