Многопользовательский контроль доступа: репозиторий или сервисный уровень?

Question

В мультитенантном приложении ASP.NET MVC, основанном на витрине MVC Роба Конери, следует ли фильтровать данные арендатора в хранилище или сервис слой?

1. Фильтровать данные клиента в хранилище:

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

2. Позвольте сервису отфильтровать данные репозитория по клиенту:

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

Мое чутье говорит сделать это на уровне обслуживания (вариант 2), но можно утверждать, что каждый арендатор по сути должен иметь свой собственный "виртуальный репозиторий" (вариант 1), где эта ответственность лежит на хранилище.

• Какой самый элегантный подход: вариант 1, вариант 2 или есть лучший способ?

---

Обновление:

Я попробовал предложенную идею фильтрации в репозитории, но проблема в том, что мое приложение предоставляет контекст арендатора (через поддомен) и взаимодействует только с сервисным уровнем. Передача контекста до уровня хранилища - это миссия.

Поэтому вместо этого я решил отфильтровать свои данные на уровне обслуживания . Мне кажется, что хранилище должно представлять все физически доступные в хранилище данные с соответствующими фильтрами для извлечения специфичных для арендатора данных, которые будут использоваться сервисным уровнем.

Окончательное обновление:

В итоге я отказался от этого подхода из-за ненужных сложностей. Смотрите мой ответ ниже.

Answer 1

@ FreshCode, мы делаем это в репозитории и не передаем арендатора в качестве параметра. Мы используем следующий подход:

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

Контекст является зависимостью репозитория, которая создается в BeginRequest, где вы, например, определяете владельца на основе URL. Я думаю, что таким образом это довольно прозрачно, и вы можете избежать параметра tenantId, который может стать немного беспокоящим.

Привет.

Answer 2

Обновление: Отсутствие мультитенантного подхода стоило мне сотен часов технического долга. Четыре года спустя, я хотел бы сначала уделить время внедрению подхода чистого арендатора. Не делай ту же ошибку!

---

Старый, устаревший ответ:

В итоге я удалил весь мультитенантный код в пользу использования отдельных приложений и баз данных для каждого арендатора. В моем случае у меня мало арендаторов, которые меняются не часто, поэтому я могу это сделать.

Все мои контроллеры, поставщики членства, поставщики ролей, сервисы и репозитории стремились повсеместно дублировать код .WithTenantID(...), что позволило мне понять, что мне действительно не нужна одна таблица Users для доступа к данным специфичен для одного арендатора в 99% случаев, поэтому использование отдельных приложений становится более понятным и делает все намного проще.

Спасибо за ваши ответы - они заставили меня понять, что мне нужен редизайн.