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

Question

我已经实现了存储库模式，它运行得很好。

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        
}

当我想从Controller中的IServiceRepository访问一些方法时，我这样做

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;
    }
}

如您所见，我在此场景中注入了IRepositories和IServiceRepository 。 有时我会根据需要仅注入IRepositories或IServiceRepository 。

问题可能是我应该将所有IRepositories移动到IServiceRepository 。 并且在所有控制器中只嵌入IServiceRepository并从IServiceRepository访问IRepositories ？ 这个实现对我来说更清楚，因为只有IServiceRepository会被注入到控制器中。 但是要访问例如ServiceRepository一个Repositorie<User> ，需要在ServiceRepository构建并注入所有其他存储库，因此可能会降低整个应用程序的速度。 你怎么看？

Answer 1

我的回答是有争议的，所以请耐心等我:)

到了这一点
构建和注入存储库几乎不需要时间。 我假设您的存储库在创建时不会打开任何连接，所以不要打扰微优化，只需让它工作:)

您可以合并您的接口，只要结果接口很小（例如，方法不超过10个），专注且具有明确的目的。

---

一边评论
存储库模式需要什么？ 您是否允许（或在最近的计划中）轻松地在数据库之间切换？ 对于大多数情况，存储库是一个巨大的过度杀伤和维护问题。

考虑这段代码

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

它告诉我什么？ 好吧，从通用名称我无法理解这个接口的作用，它就像服务的服务，抽象的抽象。 但是根据方法定义，我看到它对User做了一些事情。

为什么要明确使用IUnitOfWork ？ 您使用的数据提供程序尚未实现吗？

而不是所有这些架构 （当然，如果可能的话），只需直接使用ORM，这很容易做到和维护，可靠和快速。

Answer 2

您的ServiceRepository似乎更接近服务层中的域服务而不是自己的存储库。

域服务通常协调与各种数据存储库的交互序列，例如从客户存储库加载客户和从订单存储库加载订单列表以呈现客户及其所有订单的统一视图。 因为这样的域服务用于在应用程序周围创建操作边界 - 抽象出各种数据访问序列。

这是一个很好的方法，但我认为你遇到的问题是你没有采取足够的措施。 如果您决定将应用程序的操作封装到一系列域服务中，那么Controller将无需访问存储库。 另一方面，如果您决定控制器将采用该可重用性并自行访问存储库，那么您的ServiceRepository类和其他类似的类基本上成为实用程序类。

我看到你有两个选择 - 将服务层改进到控制器不再需要存储库的程度：

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

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

或调用ServiceRepository它是什么，一个用于执行固定数据访问序列的快捷工具...

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...
    }
}