Ограничить доступ к ресурсам базы данных в Entity Framework + UoW + Общие репозитории

Я использую ASP.NET MVC3 с Entity Framework 4.

Я использую шаблон Unit of Work + Generic Repository.

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

У нас есть база данных с несколькими арендаторами.

Представьте себе базу данных с аналогичной структурой:

  • клиентов
  • группы, связанные с клиентом
  • пользователи, связанные с одной или несколькими группами

И тогда для каждого клиента у нас есть

  • ресурсы, связанные с одной или несколькими группами и связанные между собой с внешними ключами, отношения «многие ко многим» и т. д.

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

Теперь проблема заключается в следующем:

Я внедрил некоторую предварительную фильтрацию с предложением Where() в единицу работы в репозиториях на основе идентификатора зарегистрированного пользователя.

И это работает.

Предварительная фильтрация, которую я делал в репозиториях, работает нормально, но, конечно, она работает только при непосредственном доступе к хранилищу источников TYPE A или TYPE B или TYPE C и так далее.

Но ресурс связан с другими ресурсами со многими-ко-многим таблицами и внешними ключами.

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

Если я пересекаю свойства навигации «родительского» ресурса, пользователь может получить доступ ко всем связанным ресурсам, даже к принадлежащим другим группам.

Итак, если вы начинаете с ресурса TYPE A и перемещаете свойства навигации для доступа к ресурсам TYPE B и TYPE C, они не фильтруются.

Если вы обращаетесь к репозиториям TYPE B и TYPE C, они фильтруются.

Теперь мои фильтры, как я уже говорил, входят в класс Unit Of Work, но я попытался переместить их в настраиваемый DBC-текст, применяя фильтры непосредственно в DBSet, но ничего не меняется:

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

Что мы можем сделать?

Я вижу, что NHibernate имеет глобальные фильтры, которые могут выполнить мою задачу, поэтому я оцениваю переход от EF к NH.

Я вижу, что многие другие люди просят фильтры .Include (), таким образом отключая ленивую загрузку.

Спасибо.

При необходимости я могу предоставить код, но надеюсь, что правильно объясню свою проблему.

Благодарю вас.

С наилучшими пожеланиями,

Marco

2
nl ja de

1 ответы

Я видел решение с сопоставлением с представлениями и хранимыми процедурами, но я не уверен, как сильно это было в разработке и maintanace. Короче говоря, можно отобразить EF-модель в представлениях, где данные будут отфильтрованы; в этом решении каждый пользователь имеет собственные учетные данные для базы данных.

0
добавлено
Отлично, но эта функция является одним из 10 запросов на uservoice.com по крайней мере в последние два года, поэтому шансы не очень хорошие.
добавлено автор Oleg, источник
Спасибо за ваш ответ, Олег. Я понимаю ваше решение, но я боюсь, что это будет больно поддерживать, поэтому я буду ждать других предложений. Кстати, спасибо. Кто-нибудь знает, будет ли EF 5 или EF 6 реализовывать какой-то .Include (, или, возможно, глобальные фильтры? Кто-нибудь, кто экспериментирует с NHibernate, может сказать мне, могу ли я выполнить эту задачу с помощью глобальных фильтров?
добавлено автор Marco S., источник
У кого-нибудь есть другие решения? Боюсь, я думаю, что мне придется мигрировать в NHiberanate.
добавлено автор Marco S., источник
FYI, я открыл проблему con Codeplex, и команда Entity Framework сказала, что они будут оценивать сценарий будущих выпусков. entityframework.codeplex.com/workitem/945
добавлено автор Marco S., источник