Доброго времени суток.
Столкнулся со следующими проблемами.

Есть некоторая система, работающая по следующему принципу:

База данных (SQL Server), в которой настроены роли пользователей (Role1, Role2, ...)

Бизнес объекты.

А также dal слой для конструирования бизнес объектов и сохранения состояний.

Все это реализовано на клиенте. Сервером выступает сам SQL Server — клиентское приложение самостоятельно формирует запросы и отсылает их на сервер для выполнения.

Возникли следующие трудности:

1. Как работать с ролями пользователей на уровне бизнес логики? Например у нас есть таблица Table1. Есть 4 роли: tblInsert, tblUpdate, tblSelect, tblDelete, которые соответственно разрешают выполнение операций по добавлению, чтению и модификации данных в таблице. Сейчас все роли получаются через da слой и преобразуются к статическому перечислению
Теперь при выполнении операций над каким — то бизнес объектом мне требуется запретить отображение тех функций, на которые у пользователя нет прав. Сейчас это сделано в следующем виде:

 if (User.UserRole == UserRole.RoleA)
 {
    // отобразить пункты меню, характерные для роли RoleA
 }

 if (User.UserRole == UserRole.RoleB)
 {
    // отобразить пункты меню, характерные для роли RoleB
 }

Сейчас уже понял, что такой подход неудобен следующим — а именно привязкой к текущей системе безопасности на сервере. Если на таблицы будут наложены новые ограничения — то придется переписывать огромный кусок однородного кода. А пользователи старых приложений будут получать исключения вида "Update Permission Denied"

2. Синхронизация данных
Вторая трудность синхронизация данных.
Допустим два пользователя загружают один и тот же бизнес объект и работают с ним. Потом каждый сохраняет его (подготавливает команду Update и выполняет ее). Фактически теперь каждый думает, что он сохранил объект и у него актуальное состояние. Как в этом случае сделать синхронизацию? Чтобы по крайней мере у других пользователей отобразились необходимые изменения?


Заранее спасибо за помощь

Здравствуйте, Барышников Кирилл, Вы писали:

БК>Доброго времени суток.
БК>Столкнулся со следующими проблемами.

БК>Есть некоторая система, работающая по следующему принципу:

БК>База данных (SQL Server), в которой настроены роли пользователей (Role1, Role2, ...)

БК>Бизнес объекты.

БК>А также dal слой для конструирования бизнес объектов и сохранения состояний.

БК>Все это реализовано на клиенте. Сервером выступает сам SQL Server — клиентское приложение самостоятельно формирует запросы и отсылает их на сервер для выполнения.

БК>Возникли следующие трудности:

БК>1. Как работать с ролями пользователей на уровне бизнес логики? Например у нас есть таблица Table1. Есть 4 роли: tblInsert, tblUpdate, tblSelect, tblDelete, которые соответственно разрешают выполнение операций по добавлению, чтению и модификации данных в таблице. Сейчас все роли получаются через da слой и преобразуются к статическому перечислению
БК>Теперь при выполнении операций над каким — то бизнес объектом мне требуется запретить отображение тех функций, на которые у пользователя нет прав. Сейчас это сделано в следующем виде:

БК>

БК> if (User.UserRole == UserRole.RoleA)
БК> {
БК>    // отобразить пункты меню, характерные для роли RoleA
БК> }

БК> if (User.UserRole == UserRole.RoleB)
БК> {
БК>    // отобразить пункты меню, характерные для роли RoleB
БК> }

БК>

БК>Сейчас уже понял, что такой подход неудобен следующим — а именно привязкой к текущей системе безопасности на сервере. Если на таблицы будут наложены новые ограничения — то придется переписывать огромный кусок однородного кода. А пользователи старых приложений будут получать исключения вида "Update Permission Denied"

Как сделано у меня:
if(UserAccessManager.IsUserHasPermition(User, AccessType)) {....}
где UserAccessManager — манагер прав польз., абстрагирующийся от конкретных сущностей (то ли это права на оперирование с БД, файлами, ресурсами).
AccessType — перечисление типов возможных доступов польз-й (read,write,edit,...).
Итого:
1) С помощью UserAccessManager вы не привязаны в конкретике, в вашем случае — к системе безопастности БД. UserAccessManager м.б. выполнен как абстрактная фабрика для изменения источника контроля.
2) Если будут наложены (на таблицы) новые виды ограничения, то старые польз. даже не почувствуют этого, ГЛАВНОЕ чтобы уже существующие типы доступа не меняли своего назначения! Соотв. ничего переписывать не надо.


БК>2. Синхронизация данных
БК>Вторая трудность синхронизация данных.
БК>Допустим два пользователя загружают один и тот же бизнес объект и работают с ним. Потом каждый сохраняет его (подготавливает команду Update и выполняет ее). Фактически теперь каждый думает, что он сохранил объект и у него актуальное состояние. Как в этом случае сделать синхронизацию? Чтобы по крайней мере у других пользователей отобразились необходимые изменения?

ИМХО, давать редактировать объекты более обному польз-лю — путь в корне не верный. Т.к. не понятно что есть "отобразились необходимые изменения" ? Это будут в конечном счете данные введенные польз-лем, последним его редактировавшем.
Изайте логическую(отдельная таблица блокировок в БД) или физ.(UPDLOCK для M$ SQL) блокировку объектов (записей в таблице).