在Repository模式加载子记录 [英] Loading Subrecords in the Repository Pattern

查看:123
本文介绍了在Repository模式加载子记录的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

使用LINQ to SQL作为一个基于资源库的解决方案的基础。我的实现如下:

Using LINQ TO SQL as the underpinning of a Repository-based solution. My implementation is as follows:

IRepository

IRepository

FindAll
FindByID
Insert
Update
Delete

然后,我有扩展

WhereSomethingEqualsTrue() ...

我的问题如下:

我的用户资料库有N个角色。难道我创建一个角色存储库来管理角色?我担心,我会最终创造几十个库(1每桌几乎除了连接表),如果我走这条路。每张表中的普通一库?

My Users repository has N roles. Do I create a Roles repository to manage Roles? I worry I'll end up creating dozens of Repositories (1 per table almost except for Join tables) if I go this route. Is a Repository per Table common?

推荐答案

如果你正在建立档案库具体到一个实体(表),这样,每个实体都在你的IRepository界面,你上面列出的方法列表,然后你真正做的是一个实施的活动记录模式。

If you are building your Repository to be specific to one Entity (table), such that each Entity has the list of methods in your IRepository interface that you listed above, then what you are really doing is an implementation of the Active Record pattern.

您应该的绝对不会的有每桌一个存储库。你需要确定你的域模型的聚合,并要对它们执行的操作。用户和角色通常是紧密相关的,一般你的应用程序将与他们一前一后执行操作 - 这要求单个存储库,围绕用户,它的设置密切相关的实体。

You should definitely not have one Repository per table. You need to identify the Aggregates in your domain model, and the operations that you want to perform on them. Users and Roles are usually tightly related, and generally your application would be performing operations with them in tandem - this calls for a single repository, centered around the User and it's set of closely related entities.

我从您的文章,你已经猜的seen这个例子。这个例子的问题是,所有的仓库都在共享基础级别相同的CRUD功能,但他没有超越这一点,并实现任何的域功能。在这个例子中所有的仓库看起来是一样的 - 但在现实中,真正的仓库不看起来都一样(尽管他们仍然应该接口),会有与之关联的特定域操作

I'm guessing from your post that you've seen this example. The problem with this example is that all the repositories are sharing the same CRUD functionality at the base level, but he doesn't go beyond this and implement any of the domain functions. All the repositories in that example look the same - but in reality, real repositories don't all look the same (although they should still be interfaced), there will be specific domain operations associated with each one.

您库域操作应该看起来更像是:

Your repository domain operations should look more like:

userRepository.FindRolesByUserId(int userID)
userRepository.AddUserToRole(int userID)
userRepository.FindAllUsers()
userRepository.FindAllRoles()
userRepository.GetUserSettings(int userID)

等等...

这是具体操作,你的应用程序要对基础数据进行,和存储库应当提供。认为它作为存储库表示一组,你将在域中执行原子操作。如果您选择通过一个通用的存储库来分享一些功能,并扩展方法扩展特定信息库,这是一种方法,可能会工作得很好,你的应用程序。

These are specific operations that your application wants to perform on the underlying data, and the Repository should provide that. Think of it as the Repository represents the set of atomic operations that you would perform on the domain. If you choose to share some functionality through a generic repository, and extend specific repositories with extension methods, that's one approach that may work just fine for your app.

一个很好的规则拇指是它应该是的罕见的为您的应用程序需要实例多个存储库来完成的操作。需要确实出现,但如果你的应用程序的每一个事件处理程序是杂耍6只仓库拿用户的输入,并正确实例化输入代表的实体,那么你可能有设计问题。

A good rule of thumb is that it should be rare for your application to need to instantiate multiple repositories to complete an operation. The need does arise, but if every event handler in your app is juggling six repositories just to take the user's input and correctly instantiate the entities that the input represents, then you probably have design problems.

这篇关于在Repository模式加载子记录的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆