Уровень доступа к данным - Использование сессий для данных CRUD

Question

У меня есть данные продукта DAL to CRUD.

Например:

Order someOrder = new Order();
someOrder.Description = "Test";

someOrder.Save();
someOrder.Remove();

Мне нужно спроектировать DAL, чтобы только пользователи, у которых есть блокировка объекта типа Order, могли выполнять операции CRUD.

Моя идея - передать сессию методам CRUD. После прохождения сеанса метод проверит, имеет ли этот пользователь блокировку для этого конкретного объекта, и, если да, он продолжит выполнение этого метода.

Например:

someOrder.Save(sessionThatContainsLockInformation);

// Pseudo-code
public void Save(Session session)
{

   1. Get user GUID from the session.
   2. Get lock details from the session.
   3. Check that the provided user has a lock.
   4. On success, proceed with saving the order.

}

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

Может кто-нибудь сообщить мне, является ли это разумным подходом, или он имеет некоторые фундаментальные недостатки или накладные расходы на обслуживание?

Любые альтернативные решения приветствуются. Мне не интересен код, просто некоторые идеи, пожалуйста.

Спасибо

Answer 1

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

Я столкнулся с подобной проблемой некоторое время назад. Моим решением был общий суперкласс (в ваших классах это был бы суперкласс для Order, Item, Customer) со всеми одинаковыми параметрами (временная метка изменена, кто внес изменения и т.д.) Затем я создал служебный класс, в котором были учтены все упомянутые вами проверки. Таким образом, эта логика «обслуживания» реализована только в одном месте.

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

Надеюсь, это поможет, Jan

Answer 2

Это всего лишь пара идей, в зависимости от постоянства API по вашему выбору. Я считаю, что Hibernate предлагает некоторые механизмы «оптимистической / пессимистической блокировки». Я не знаю точных деталей того, как они работают, но вы должны быть в состоянии найти что-то на домашней странице спящего режима (в случае, если вы хотите использовать спящий режим). http://docs.jboss.org/hibernate/core/3.3/reference/en/html/mapping.html

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/transactions.html#transactions-locking

Простой (возможно, слишком простой, зависит от текущей ситуации ...) подход «сделай сам» может иметь простую строку timestampChanged. Во время записи в БД вам нужно будет проверить, совпадает ли отметка времени, которую вы хотите сохранить, с последней отметкой времени в БД. Но, как я уже сказал, не все приложения подходят для этого ...

Надеюсь, это поможет, Jan

Answer 3

Спасибо за ваш ответ. Мои методы CRUD работают, и у меня там нет проблем.

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

Заказать Вещь Клиент

Каждый из этих классов имеет следующие методы: .Сохранить() .Remove ()

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

Public void Save (подробности UserAndLockDetails) {

}

Теперь у меня 50 классов вместо 3, что означает, что есть 100 методов (Save (), Remove ()), которые мне придется обновлять при изменении требований. Я рассматриваю это как накладные расходы на техническое обслуживание, но я не могу думать о каких-либо альтернативных решениях.

Надеюсь, это имеет смысл.

Спасибо