LLBLGen和存储库模式

Question

我想知道在顶层LLBLGen (适配器)上构建一个存储库是不是一个好主意。我不想过度设计和重新发明轮子。DataAccessAdapter类可以是某种通用的repository.It，它包含您需要的所有CRUD方法。

但另一方面，对于较大的项目，在ORM和服务层之间设置一个层可能会更好。

我想听听你的意见，如果你在LLBLGen中使用存储库模式，如果是，为什么不是，为什么不是。

如果你有一些实现，请把它贴出来。

Answer 1

直接的好处是避免锁定特定的技术，使您以后可以灵活地选择适当的技术。

我想，一个更重要的原因是执行Ubiquitous Language。随着应用程序/系统的发展，您将需要以多种方式查询数据。Repository可以帮助您封装复杂的查询。

对于通用实现，您的使用者代码可能如下所示：

customerRepo = ServiceLocator.Current.Resolve<IRepository<Customer>>();
var matchingCustomers = customerRepo.GetAll().Where(c => <some complex condition here>);

使用存储库，它将如下所示：

customerRepo = ServiceLocator.Current.Resolve<ICustomerRepository>();
var matchingCustomers = myRepo.GetCustomersWithOrdersPendingFor(new DateTime(2010, 12, 31));
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

第二个示例明确地说明了查询的目的，使其在将来更容易/更快地识别。

但是(使问题更加复杂)，您可以使用查询规范来隔离复杂的查询逻辑，然后将其与通用存储库一起使用来完成这项工作。请参阅this post以了解它是如何完成的。

我通常会执行以下操作：

Create too >创建通用存储库(即，为每个聚合根创建IRepository)

• Create存储库，根据需要对相应的repository

• When实现IRepository

• Add

• 方法存储库变得过于臃肿，将查询重构为单独的查询Specifications

最后一点:我曾经设计过一个既能在在线模式下也能在离线模式下工作的应用程序。最简单的解决方案是实现两个具体的存储库(使用公共接口)，并在客户端连接/断开时在它们之间切换(切换持久性技术的另一个示例)。

Answer 2

我们将存储库与LLBLGen一起使用，但是使用了自助服务。我们使用存储库模式来简化我们的单元测试。对于简单的插入/更新，存储库只是调用传入实体的save方法。我们最终的目标是在存储库和业务逻辑之间来回传递域对象(而不是LLBLGEN实体)，并且在实现的存储库中只有ORM (LLBLEN、LINQ-To-SQL等)依赖项。