ansaurus

Question

Answer 1

A:

unless I misread something, the accepted answer in the question you linked doesn't use generics. He is defining an Interface and using the term "generic" to mean the Interface isn't tied directly to any specific table in the model.

Geoff 2009-07-08 19:44:39

I don't think that's the case, but if it is, what would be the signatures of those 7 functions in IEntityRepository look like?

mgroves 2009-07-08 19:48:29

He is referring to the repository implementation that uses the IRepository<TEntity> interface.

Enrico Campidoglio 2009-07-08 19:54:57

Answer 2

+1 A:

It's very possible but you either have to not use a common interface or do a lot of casting. Using an interface ...

public interface IRepository
{
    public object Get(int id); // or object id
    public void Save(object obj);
}

public class CustomerRepository : IRepository
{
    public object Get(int id) { // implementation }
    public void Save(object obj) { // implementation }
}

This works fine but calling code has to cast objects to the correct type and methods in concrete implementations have to check type and throw exceptions. Direct casting is asking for runtime exceptions so I would avoid this approach.

The approach I would recommend is to not have your repositories implement a common interface. Instead have them implement commonly named methods by convention.

public class CustomerRepository
{
    public Customer Get(int id) { // implementation }
    public void Save(Customer entity) { // implementation }
}

public class EmployeeRepository
{
    public Employee Get(int id) { // implementation }
    public void Save(Employee entity) { // implementation }
}

Edited to add: I reread the linked answer. The last full paragraph loses me but I can expand a bit on using DI. In most cases it wouldn't make sense to use DI to inject a "generic" (in this case meaning derived from a common interface) repository. In addition to the common methods, a repository will have entity specific methods such as GetCustomersWithPastDueAccounts. You could define an ICustomerRepository with that method and have your CustomerRepository implement that. Then you could use dependency injection to inject CustomerRepository at runtime. There's nothing wrong with that, but in my experience it's fairly rare that you would have multiple implementations of a repository so there's little point in doing so.

Jamie Ide 2009-07-08 19:52:39

But with your second approach, don't I lose the ability to inject dependencies?

mgroves 2009-07-08 19:54:05

You can always do manual dependency injection. But you're right, you would not be able to use a DI framework to do dependency injection. I'll edit my answer and add more explanation.

Jamie Ide 2009-07-08 20:02:27

So basically, there's an interface for each repository, and that can be used for DI. For 10 entities, 10 interfaces, with at least 10 implementations. Sound right?

mgroves 2009-07-08 20:18:27

Sounds right. Make it an even hundred entities and it qualifies as an "enterprise" application. With generics, you can use a single concrete class as a repository for an entity that does not have any additional functions beyond those defined in the base interface.

Jamie Ide 2009-07-08 20:25:24

ansaurus

tags:

views:

answers:

Repository pattern with .NET 1.1

related questions