1。在存储库中过滤租户的数据：

public interface IJobRepository
{
    IQueryable<Job> GetJobs(short tenantId);
}

2。让服务按租户过滤存储库数据：

public interface IJobService
{
    IList<Job> GetJobs(short tenantId);
}

我的直觉是在服务层（选项2）中进行，但可以说每个租户本质上应该拥有自己的“虚拟存储库”（选项1）这个责任在于存储库。

我尝试了在存储库中提出过滤的提议，但问题是我的应用程序提供了租户上下文（通过子域）并且只与服务层交互。将上下文一直传递到存储库层是一项任务。

所以我选择在服务层过滤我的数据。我觉得存储库应该代表存储库中物理上可用的所有数据，并使用适当的过滤器来检索服务层使用的特定于租户的数据。

由于不必要的复杂性，我最终放弃了这种方法。请参阅下面的答案。

Answer 1

@FreshCode，我们在存储库中执行此操作，并且我们不会将租户作为参数传递。我们使用以下方法：

public IQueryable<Job> GetJobs()
{
    return _db.Jobs.Where(j=>j.TenantId == Context.TenantId);
}

上下文是存储库具有的依赖关系，它是在BeginRequest中创建的，您可以根据该URL确定租户。我认为通过这种方式，它非常透明，您可以避免tenantId参数，这可能会让您感到有点不安。

问候。

Answer 2

更新：不采用多租户方式需要花费数百小时的技术债务。四年后，我希望我先花时间实施一个干净的租户方法。不要犯同样的错误！

我最终剥离了所有多租户代码，转而为每个租户使用单独的应用程序和数据库。在我的情况下，我很少有租户不经常改变，所以我可以这样做。

我的所有控制器，成员资格提供者，角色提供者，服务和存储库都倾向于遍布整个地方的重复.WithTenantID(...)代码，这让我意识到我并不需要一个Users表来99％的时间访问特定于一个租户的数据，因此使用单独的应用程序更有意义，并使一切变得更加简单。

感谢您的回答 - 他们让我意识到我需要重新设计。