3

我想知道在顶部 LLBLGen（适配器）上构建存储库是否是个好主意。我不想过度设计和重新发明轮子。DataAccessAdapter 类可能是某种通用存储库。它具有您需要的所有 CRUD 方法。

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

如果您将存储库模式与 LLBLGen 一起使用，我想听听您的意见，如果是，为什么如果不是，为什么不。

如果您有一些实现，请发布。

4

2 回答 2

2

直接的好处是防止锁定到特定技术，让您以后可以灵活地选择合适的技术。

恕我直言，一个更重要的原因是强制执行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));
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

第二个示例明确说明了查询的意图，以便将来更容易/更快地识别。

但是（只是为了使事情复杂化），您可以使用查询规范来隔离复杂的查询逻辑，然后使用通用存储库来完成工作。请参阅这篇文章以了解它是如何完成的。

我通常会做以下事情：

  1. 创建一个通用存储库（即IRepository<TAggregateRoot>）
  2. 为每个聚合根创建存储库，实现IRepository<TAggregateRoot>
  3. 根据需要将查询方法添加到适当的存储库
  4. 当存储库变得过于臃肿时，将查询重构为单独的查询规范

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

于 2010-12-30T10:17:02.757 回答
1

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

于 2010-12-22T16:42:52.410 回答