Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Бизнес-логика и интерфейс пользователя  [new]
minva
Member

Откуда: г. Калуга
Сообщений: 1206
Очень много читал рекомендаций о том, что бизнес-логику нужно реализовывать в ХП на сервере. Почти полностью согласен. НО… такой пример. Пусть есть запись, которую при определённых условиях нельзя редактировать. Бедный юзер старается, вносит изменения, нажимает OK и получает красивое сообщение: «Обломайся». Всё потому, что все проверки реализованы после нажатия OK, т.е. во время записи на сервер. По идее нужно запретить пользователю нажимать на кнопку «Редактирование». Для этого с клиента нужно на сервер послать кучу запросов на проверку бизнес-правил. Если пользователю можно редактировать, то он этим и занимается, по при записи опять происходит проверка тех же самых бизнес-правил… Вопрос, зачем проверять, когда запрет на редактирование уже реализован на уровне кнопки. Незачем, но тогда логика построения базы остается беззащитной перед простым update, сделанным из OA .
Если я вас не совсем запутал, то расскажите, пожалуйста, как это делается. Связка интерфейса и бизнес-правил на сервере
2 сен 03, 22:55    [324143]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
злой шаман
Member

Откуда: Питер
Сообщений: 1253
Посмотрите, только что был топик про защиту:
https://www.sql.ru/forum/actualthread.aspx?bid=1&tid=46442
3 сен 03, 00:26    [324180]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
bushmen
Member

Откуда: г. Москва
Сообщений: 828
Чтобы зайти в QA нужно, между прочим, тоже пароль ввести.
Кто мешает создать дополнительную таблицу на сервере с указанием прав доступа юзеров?! После авторизации проверяй с клиента уровень доступа и занеси в массив.
3 сен 03, 09:45    [324359]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
Glory
Member

Откуда:
Сообщений: 104760
Пусть есть запись, которую при определённых условиях нельзя редактировать. Бедный юзер старается, вносит изменения, нажимает OK и получает красивое сообщение: «Обломайся».

Если запись нельзя редактировать, так может быть ее вообще НЕ выдавать клиенту? Или в возвращаемом наборе сразу добавлять для этого какой-нибудь признак ?
3 сен 03, 10:28    [324427]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
minva
Member

Откуда: г. Калуга
Сообщений: 1206
Если запись нельзя редактировать, так может быть ее вообще НЕ выдавать клиенту? Или в возвращаемом наборе сразу добавлять для этого какой-нибудь признак ?

Меня не поняли. Что значит не выдавать? Смотреть то он её может. И редактировать он её может, т.е. имеет права, но только при опредёленных условиях. Ещё раз объясняю, где неувязка:
1. Чтобы запретить пользователю (т.е. отключить соответсвующую кнопку) что либо редактировать надо проверить условия. Условия проверяются на клиенте или сразу с сервера возращаются в виде признака, не важно. Важно то, что они проверяются в процессе просмотра записи, а не в процессе её сохранения.
2. Хорошо, пусть будет защита от редактирования на уровне кнопки. А если пусть даже администратор будет делать апдейт из QA? Кто его будет проверять, если при записи мы проверку убрали? Во-первых он может ошибиться, а во-вторых не будет же он ручками проверять все ли условия выполняются. Если что-то не так, то его должен отфутболить сервер. А так получается, что на уровне приложения логика соблюдается, а на уровне базы нет.
3. Хорошо, сделаем логику и там и там. Но тогда это уже дублирование. Это тоже не очень по моему.
3 сен 03, 11:29    [324551]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
iSestrin
Member

Откуда: Новосибирск
Сообщений: 3811
реализуешь бизнес-логику в ХП, которые помимо данных выдают для каждой записи флажок, можно или нет редактировать данную запись... таким образом проверка на клиенте упрощается до неприличия
3 сен 03, 11:37    [324571]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
bushmen
Member

Откуда: г. Москва
Сообщений: 828
А если пусть даже администратор будет делать апдейт из QA?

Администратор зайдёт в EM и введёт любую запись, не смотря ни на какие ограничения в SP :)
3 сен 03, 11:37    [324573]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
iSestrin
Member

Откуда: Новосибирск
Сообщений: 3811
собственно Glory об этом и написал, ты просто не обратил внимание на 2-е предложение, и все возражения сделал на 1-е
3 сен 03, 11:39    [324575]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
-----------
Guest
администратор приложения не обязательно dbo,
а тем более sa.
и мимо хранимой процедуры ничего не сделает.
а от dbo и sa защищаться - глупо.
3 сен 03, 11:40    [324580]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
Glory
Member

Откуда:
Сообщений: 104760
И редактировать он её может, т.е. имеет права, но только при опредёленных условиях.

Когда вы возвращает пользователю набор вы знаете о факте выполненения/невыполнения этих определенных условий для пользователя ?
Если знаете, то почему не вернуть в наборе служебное поле 1/0 ?
3 сен 03, 11:41    [324583]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
bushmen
Member

Откуда: г. Москва
Сообщений: 828
Ведь, действительно, можно из ХП вернуть хотя бы сообщение, что пользователю запрещено редактирование конкретной записи
3 сен 03, 11:44    [324589]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
Hibernate
Member

Откуда: Киев
Сообщений: 1670
Вопрос, зачем проверять, когда запрет на редактирование уже реализован на уровне кнопки.

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

Незачем, но тогда логика построения базы остается беззащитной перед простым update, сделанным из OA

если у юзера есть доступ только к хп, то это не так.

я бы рекомендовал придердживаться правила: "нормальный сервер БД должен заботиться о себе сам" и не зависеть от клиентского приложения.
Пример: сделали мы корпоративную БД, сделали приложение для доступа, все отлично, но вот пондобился доступ к этой БД из инета, асп-приложение делали люди со стороны. Им был предоставлен доступ к хп и предоставлено описание этих хп как "черных ящиков". и все. И я не беспокоюсь, что они что-то напартачат в своем приложении - моя БД сама о себе беспокоится. Конечно все было не совсем так уж безоблачно, но тем не менее почти так.
3 сен 03, 11:46    [324596]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
minva
Member

Откуда: г. Калуга
Сообщений: 1206
я бы рекомендовал придердживаться правила: "нормальный сервер БД должен заботиться о себе сам" и не зависеть от клиентского приложения

я тоже стараюсь так делать... Но согласитесь, что вы читаете записи одной ХП, а пишите другой. Значит логика проверяется в первой ХП, чтобы выдать 0 или 1. Пусть будет 1 - редактировать можно. Записываем второй ХП, там опять проверяется таже логика. Вот я и спрашиваю ЭТО НОРМАЛЬНО?

тут еще вот какая "фишка" - эти самые условия могут измениться за время редактирования (мы ведь в многопользовательском режиме?).

Ну тут зависит от того, что именно делается. В моём случае до конца рабочего дня (после запуска приложения) эти условия точно не поменяются :-)
3 сен 03, 12:08    [324644]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
Glory
Member

Откуда:
Сообщений: 104760
Записываем второй ХП, там опять проверяется таже логика. Вот я и спрашиваю ЭТО НОРМАЛЬНО?

Если был 0, то процедура вообще не должна вызываться.

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

Если была 1 и редактирование осуществляется на конкуретной основе то это уже ваша логика.
3 сен 03, 12:15    [324663]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
minva
Member

Откуда: г. Калуга
Сообщений: 1206
Если был 0, то процедура вообще не должна вызываться.

Логично, кнопка то задизейблена :-)

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

А т.е. из программы я в процедуру записи посылаю 1, и оня ничего не проверяет. Посылать туда 0 бессмыслено, т.к. см. выше. Нахрена тогда проверка?

А приджоступе не из клиента процедура безззащитна.

Вы меня не понимаете или я тупой
3 сен 03, 12:25    [324692]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
Glory
Member

Откуда:
Сообщений: 104760
В том-то и дело что непонятно как вы рассматриваете(а значит и реализуете) ваш бизнесс-процесс "редактирование" ?
Одно дело как 3 независимых универсальных блока - выборка, редактирование и запись результатов.

Другое дело как один блок.
3 сен 03, 12:35    [324726]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
minva
Member

Откуда: г. Калуга
Сообщений: 1206
Выборка делается вьюхой.
Отрывается диалоговое окно, юзер заносит/редактирует данные, все это отправляется в ХП. в ней обычные Insert и update практически без проверок. Все проверки логики в триггере. он один на обновление и вставку, в зависимости от операции логика внутри него разветвляется, но не сразу, сначала общие проверки.
После закрытия окна обновление данных в гриде

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

Что здесь плохо - скажите. Я пока недостаток вижу в том, что те же проверки (по крайней мере можно/нельзя) надо реализовывать на уровне интерфейса
3 сен 03, 17:30    [325400]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ну и выноси поле дополнительное 0\1.
Или у тебя проверки 100 строк кода занимают?
Тогда вынеси их в отдельную ХП. И запускай и там и тут.
Либо запускай при открытии окна для редактирования эту же ХП.

Да и селекты из ХП же и выдавай - так гораздо лучше подготовить результат для выдачи клиенту
3 сен 03, 17:49    [325433]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
minva
Member

Откуда: г. Калуга
Сообщений: 1206
Ладно убедили...
Кстати tygra тогда попутно вопрос
Как Вы из ХП возвращаете наборы данных?
В ХП делаете тот же селект, что можно было из без ХП сделать или формируете какую либо временную таблицу или ещё варианты...
3 сен 03, 17:56    [325450]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
В ХП тоже делаем селект :)
Если надо - то и через временную таблицу.

что можно было из без ХП сделать
понимаю, понимаю

Во-первых, на ХП строится вся система безопасности - в том числе и на просмотр.
Во-вторых - в 99% перед селектом нужно кое-что еще делать (иногда это кое-что занимает не один десяток строк кода:)). И в этом случае без ХП не обойтись.
И зачем тогда мешанину разводить - и ХП, и не ХП?
Ничем не хуже дергать ХП даже для селекта чем прямой селект из клиента. Не, даже точнее - многим лучше такой подход. Любое исправление вносится в ХП не затрагивая никак клиента. В реальном времени.

ЗЫ По этому поводу столько копий сгорело.... Мы с pkarklin даже книгу хотели писать - как правильно работать из клиента с SQL сервером. Но времени нет. Хотя может написали бы, продали - через мой же Озон например - разбогатели быыыыы..... :)
3 сен 03, 18:11    [325488]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
minva
Member

Откуда: г. Калуга
Сообщений: 1206
По этому поводу столько копий сгорело...

Угу. Читал. Иногда я думал - хорошо, что не живьем общаетесь. :-)
3 сен 03, 18:41    [325535]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
Hibernate
Member

Откуда: Киев
Сообщений: 1670
чем еще лучше через хп селектить - это тем, что из нее можно вернуть несколько наборов (например, данные и информация по их форматированию/раскрашиванию)

или вариант - надо обновить список на клиенте, на сервер передаем время формирования предыдущего списка, а с сервера возвращаем только то, что изменилось с того времени.
Вобщем вариантов масса :-)

Это-же можно реализовать и несколькими запросами, но когда все нужное собрано в одном месте - так удобнее.

а по поводу проверок можно/нельзя мы поступили несколько по-другому (не очень хорошо но уж так получилось), а мыслили примерно так: сервер выдает данные, а уж дело приложения на основании этих данных делать вывод о том какие там кнопки делать доступными а какие нет - тоесть часть бизнес-логики реализована в приложении, но при занесении данных в БД, уже сама бд проверяет корректность этих данных.
Еси подитожить, то что получается:
- либо сервер должен знать о "кнопках", и прочих финтифлюшках клиентского приложения и управлять их состоянием/форматированием.
- либо клиентское приложение должно обладать неким интеллектом (частью бизнес-логики сервера) чтобы самому решать как и что изображать.

В вырожденном виде первого варианта клиентское приложение есть ничто иное, как движок, выполняющий команды сервера по формированию формочек, меню, тулбаров, списков, элементов управления и прочей лобуды.
И понадобится еще одно приложение, которое будет способно давать возможность визуально рисовать формочки, увязывать их с бизнес-логикой и заливать эти данные в БД, по сути получаем тот-же например VB, который хранит исходные тексты на сервере, + интерпретатор, который потом это все изображает...
3 сен 03, 18:41    [325536]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
alr
Member

Откуда:
Сообщений: 51
Провокационный вопрос:)
Есть тулзы (Customizer, например) с помощью которых можно легко разрешить любой задисейбленный контрол (ну, естественно, тот у которого хендл окна есть). Как ваши приложения поведут себя в этом случае?
3 сен 03, 19:57    [325604]     Ответить | Цитировать Сообщить модератору
 Re: Бизнес-логика и интерфейс пользователя  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Провокационный ответ :)
Контрол - это всего лишь контрол. Ведь на ХП то права ты не изменишь. Нажмешь на кнопку и пошлет MS SQL на хрен со словами нет прав у тебя юзер
4 сен 03, 11:26    [326078]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить