LLBLGen 和存储库模式答案

【问题标题】：LLBLGen and the repository patternLLBLGen 和存储库模式
【发布时间】：2010-12-22 08:52:48
【问题描述】：

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

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

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

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

【问题讨论】：

标签： repository-pattern llblgenpro

【解决方案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 了解它是如何完成的。

我通常会做以下事情：

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

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

【讨论】：

我现在觉得后者更像是一个服务层，但两者都应该是独立的，将纯存储库的东西（Get()、GetAll()、GetByQuery 等）与查询特定的东西 GetCustomersWithBlah 混合的想法感觉很混乱，那么您的查询逻辑就在各个级别。在 CustomerQueryService 等中嵌套通用存储库没有害处。

【解决方案2】：

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

【讨论】：

有趣。您的 domian 对象是实体的单独对象？我猜你必须在它们之间做一些映射。
还没有，但最终。使用单独的域对象，您可以轻松地将您的数据实现从 llblgen 切换到其他东西（Linq 到 SQL、XML 等），而无需触及其他任何东西（Bll 层等）。