DataContext. Есть ли один метод, где я могу добавить дополнительные ГДЕ?

Question

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

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

.WHERE(user=>user.id=MYPARAM)

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

Есть ли быстрый выигрыш? Единственное место, где я могу указать это в .dbml?

Answer 1

Возможно, я бы динамически создал лямбда-выражение.

Предложение Where принимает объект типа Expression>

Затем вы можете создать выражение, используя следующее.

Expression<Func<User,bool>> func = null;

Тогда

ParameterExpression xParam = Expression.Parameter(typeof(User), "u");

Затем вы должны создать выражение для u.id = "test", используя двоичное выражение.

BinaryExpression uidTest = Expression.Equal(Expression.Property(xParam, "id"),
                                                               Expression.Constant("test");

и затем присоединить его к выражению следующим образом:

func = Expression.Lambda<Func<User, bool>>(uidTest, xParam)

Фактически это строит лямбда-выражение u => u.id = "test"

Объект func может затем использоваться в .Where следующим образом: .Где (FUNC)

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

Answer 2

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

ГДЕ user_id = SUSER_SNAME ()

Для этого требуется, чтобы вы динамически устанавливали свойства соединения каждого пользователя перед установлением соединения с базой данных (то есть каждый пользователь базы данных имеет определенное имя пользователя и пароль SQL). Если это не жизнеспособное решение, вы можете рассмотреть возможность построения структуры вокруг контекста L2S, чтобы вы могли внедрить свою собственную логику. Если вам нужно больше вдохновения, прочитайте здесь: http://www.west -wind.com / WebLog / posts / 160237.aspx

Answer 3

Я не уверен, что есть что-то подобное.

Если нет, вы можете предоставить уже отфильтрованные свойства для всех таблиц в частичном классе. Затем вы получите идентификатор пользователя в качестве параметра для контекста данных.

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