Which of those two entities implementations are better in ASP.net MVC

Question

I'm a beginner to ASP.net MVC. And liking it a lot more than WebForms.

So i decided to start a project which contains about 6 tables:

1. Gallery
2. Admins
3. Sessions
4. SessionImages
5. Offers
6. Info

I've created two projects : FP.WebUI and FP.Domain .

Inside my domain project i've created 3 folders Abstract , Concrete and Entities .

Inside Abstract folder there are 6 interfaces IGallery , ISessions .. etc. Each interface has something like this :

namespace FP.Domain.Abstract
{
    public interface IGallery
    {
        IQueryable<Gallery> Gallery { get; }

    }
}

And inside Concrete folder there are another 7 classes : EFDbGallery , EFDbSessions ... and EFDbContext which inherites from DbContext class.

Each class of the above (except EFDbContext ), implements each of the corresponding interface.

Now when i thought about it i found that i could make one interface which defines all the entities and only one class inside Concrete folder which implements that interface.

---

I really don't know what's better :

6 interfaces , 6 classes for each entity.

OR

1 interface , 1 class which returns all entities.

Answer 1

You seem to have stumbled upon the Repository pattern. The typical architectural decision is to create an interface

interface IRepository
{
    IQueryable<Gallery> Query { get; }
}

Then have your ORM class implement the repository interface.

class MyDbContext : DbContext , IRepository
{

}

Now at this point, to answer your question, should I use 6 classes and 6 interfaces or 1 class and 1 interface the answer is categorically NO!

The typical pattern calls for a GENERIC interface (so in effect you have 6 interfaces, but a single interface source, if you need extra calls you can extend the generic).

//Actually this implementation is edging on 
//Unit Of Work
interface IRepository<T>  
{
    IQueryable<T> Query { get; }
    void Insert(T item);
    void SaveChanges();
}

Then your EfContext exposes all of the interfaces. The reason being is that your controllers only typically need a single interface to work, and this makes mock/fake testing MUCH MUCH easier on your controllers (you don't need to create implementations of unused methods like an InfoQuery for a GalleryControllerTest).

If you find you need to have domain specific code for any interface you could extend the IRepository interface.

interface IGalleryRepository : IRepository<Gallery>  
{
    void SomeSpecialOperation(Gallery item);
}

Finally, implementation of this pattern will make life much easier if/when you start introducing Inversion of Control.

PS I typically refactor out the ACTUAL EF code (ie the concrete Repository) into a separate assembly, this is simply in case you ever decide to drop EF from your project.

Answer 2

I would use 7 classes because they will have different responsibilities.

.