repository-pattern - LLBLGen 和存储库模式

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

我通常会做以下事情:

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

最后一点:我曾经设计过一个可以在线和离线模式运行的应用程序。最简单的解决方案是实现两个具体的 Repositories(使用公共(public)接口(interface))，并在客户端连接/断开连接时在它们之间切换(切换持久性技术的另一个例子)。