3

我已经实现了存储库模式，并且效果很好。

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        
}

当我想从IServiceRepositoryController 中访问某些方法时，我会这样做

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和访问？这个实现对我来说看起来更清楚，因为只会注入控制器。但是要访问例如一个from将需要在 中构建和注入所有其他存储库，因此它可能会减慢整个应用程序的速度。你怎么看？IRepositoriesIServiceRepositoryIServiceRepositoryRepositorie<User>ServiceRepositoryServiceRepository

4

2 回答 2

3

我的回答是有争议的，所以请多多包涵:)


构建和注入存储库几乎不需要任何时间。我假设您的存储库在创建时不会打开任何连接，所以不要为微优化而烦恼，让它工作:)

你可以合并你的接口，只要结果接口很小（比如不超过 10 个左右的方法），有重点并且有明确的目的。

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

考虑这段代码

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

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

为什么要明确使用IUnitOfWork？您使用的数据提供者还没有实现它吗？

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

于 2012-07-19T11:34:08.927 回答
1

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

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

这是一个很好的方法，但我认为你遇到的问题是你还没有走得足够远。如果您决定将应用程序的操作封装到一系列域服务中，那么控制器将不需要访问存储库。另一方面，如果您决定控制器将采用该存储库并自己访问存储库，那么您的 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...
    }
}
于 2012-07-19T11:37:36.540 回答