Question

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

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

如果您使用LLBLGen的存储库模式，我想听听您的意见，如果是，为什么不这样做。

如果你有一些实施，请发布。

Answer 1

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

恕我直言，更重要的原因是强制执行Ubiquitous Language。随着应用程序/系统的发展，您需要以多种方式查询数据。存储库可以帮助您封装复杂的查询。

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

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，了解它是如何完成的。

我通常会做以下事情：

创建通用存储库（即 IRepository＆lt; TAggregateRoot＆gt; ）
为每个聚合根创建存储库，实现 IRepository＆lt; TAggregateRoot＆gt;
根据需要将查询方法添加到相应的存储库
当存储库过于膨胀时，将查询重构为单独的查询规范

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

Answer 2

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

LLBLGen和存储库模式

2 个答案: