当前位置：文江博客话题详情

LLBLGen 和存储库模式

发布于 2024-10-08 18:16:10 字数 233 浏览 2 评论 0原文

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

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

森林很绿却致人迷途 2024-10-15 18:16:10

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

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

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

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));
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

第二个示例明确说明了查询的意图，使其更容易/更快地在未来。

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

我通常会执行以下操作：

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

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

The immediate benefit is preventing lock-in to a particular technology, giving you the flexibility to choose the appropriate technology later on.

IMHO, a more important reason is to enforce the Ubiquitous Language. As your application/system evolves, you'll need to query data in multiple ways. The Repository can help you encapsulate complex queries.

With a generic implementation, your consumer code might look like this:

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

Using a repository, it would look like this:

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

The second example explictly states the intent of the query, making it easier/quicker to identify in the future.

However (just to complicate matters), you could use Query Specifications to isolate complex query logic, and use then with a generic Repository to get the job done. See this post to see how it's done.

I usually do the following:

Create a generic repository (i.e. IRepository<TAggregateRoot>)
Create repositories for each Aggregate Root, implementing IRepository<TAggregateRoot>
Add query methods as needed to the appropriate repository
When the repository gets too bloated, refactor the queries into separate Query Specifications

A final note: I once designed an app that worked in both on-line and off-line mode. The easiest solution was to implement two concrete Repositories (using a common interface), and switch between them when the client was connected/disconnected (another example of switching the persistence technology).

回复收藏 0 原文

雾里花 2024-10-15 18:16:10

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

回复收藏 0 原文

~没有更多了~