存储库模式IRepository <T> 在IServiceRepository中

Question

I have implemented repository pattern and it works pretty well.

public interface IServiceRepository
{
    User GetUser(int id);
    User GetUser(string email);
    User GetUser(string email, byte[] password);
    //SkipCode
}

//Service repository where I keep extended methods for database manipulation
public class ServiceRepository : IServiceRepository
{
    private readonly IRepository<User> _userRepository;
    private readonly IRepository<Order> _orderRepository;
    private readonly IUnitOfWork _unitOfWork;

    public ServiceRepository(IRepository<User> userRepository, IRepository<Order> orderRepository, IUnitOfWork unitOfWork)
    {
    }

    //SkipImplementation        
}

When I want to access some methods from IServiceRepository in Controller I do this

public class AccountController : Controller
{
    private readonly IRepository<OrderDetail> _orderDetailRepository;
    private readonly IRepository<UserDetail> _userDetailRepository;
    private readonly IServiceRepository _serviceRepository;

    public AccountController(IRepository<OrderDetail> orderDetailRepository, IRepository<UserDetail> userDetailRepository, IServiceRepository serviceRepository)
    {
        _orderDetailRepository = orderDetailRepository;
        _userDetailRepository = userDetailRepository;
        _serviceRepository = serviceRepository;
    }
}

As you see I inject IRepositories and IServiceRepository in this scenario. Sometimes I inject only IRepositories or IServiceRepository depending on a needs.

Question would be maybe I should move all IRepositories into IServiceRepository . And in all controllers embed only IServiceRepository and access IRepositories from IServiceRepository ? This implementation looks more clear to me because only IServiceRepository will be injected in controllers. But to access for example one Repositorie<User> from ServiceRepository will need to build and inject all other repositories in ServiceRepository , so it may slow down the whole application. What do you think?

Answer 1

My answer is controversial, so please bear with me :)

To the point
Building and injecting repositories should take almost no time. I assume your repositories do not open any connections when they are created, so do not bother about micro optimisation, just get it working :)

You can merge your interfaces, as long as the result interface is small (say no more than 10 or so methods), focused and has a clear purpose.

---

Side comments
What is the need for the repository pattern? Do you allow (or in the nearest future plan) to easily switch between databases? For most cases repository is a massive overkill and a maintenance problem.

Consider this code

 public interface IServiceRepository { User GetUser(int id); User GetUser(string email); User GetUser(string email, byte[] password); //SkipCode } 

What does it tell me? Well, from the generic name I couldn't understand what this interface does, it is like service of a service, abstraction over abstraction. But from the method definitions I see it does something with User s.

Why do you explicitly using IUnitOfWork ? Is it not already implemented by the data provider you using?

Instead of all this architecture (of course if possible), just use ORM directly, this is easy to do and maintain, reliable and fast.

Answer 2

Your ServiceRepository seems to be closer to a domain service in a Service Layer than a repository of its own.

A domain service typically coordinates a sequence of interactions with various data repositories, for example loading a customer from a customer repository and a list of orders from an order repository to present a unified view of a customer and all their orders. As such domain services are used to create an operational boundary around an application - abstracting the various sequences of data access.

This is a fine approach, but I think the problem you have is that you have not taken it far enough. If you decide that the operations of the application should be encapsulated into a series of domain services, then there will be no need for a Controller to access repositories. If on the other hand you decide that the Controllers will take that reposibility, and access repositories themselves, then your ServiceRepository class, and others like it, basically become utility classes.

I see that you have two options - improve your service layer to such an extent that controllers no longer need repositories:

public class AccountController
{
    public AccountController(IAccountsService service)
    {
        _service = service;
    }

    public void SomeActionMethod(Foo someParams)
    {
        _service.SomeAction(someParams);
    }
}

or call the ServiceRepository what it is, a shortcut utility for doing a fixed sequence of data accesses...

public class AccountController
{
    public AccountController(ICustomerRepository customerRepo, IOrderRepository orderRep)
    {
        _customerRepo = customerRepo;
        _orderRepo = orderRepo;
    }

    public void SomeActionMethod(Foo someParams)
    {
        var utility = new CustomerOrderBuilderUtility(_customerRepo, _orderRepo);

        var customerWithOrders = utility.GetCustomerAndOrders(someParams.CustomerId);

        // some domain logic...
    }
}