Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Валидация данных перед внесением в БД  (Прочитано 9993 раз)
0 Пользователей и 1 Гость смотрят эту тему.
yudjin
Помогающий

ua
Offline Offline
Пол: Мужской

« : 20-09-2010 13:52 » 

День добрый. Хочу спросить вот что. Пытаюсь освоить трехзвенку. В каком месте лучше проверять валидацию данных, заносимых в БД? На клиенте (при вводе данных шуршать таблицы через прослойку) или в промежуточном слое? бизнес-правила в самой БД учтены (при удалении - каскадом в дочерних, уникальность ВК, проч...). Если в среднем слое - то как оповещать об этом клиента? через исключения?
Или же это дело сугубо личное?
« Последнее редактирование: 20-09-2010 14:19 от yudjin » Записан
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 20-09-2010 14:28 » 

На клиенте делать защиту "от дурака"

А что такое средний слой, как он выглядит?
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
yudjin
Помогающий

ua
Offline Offline
Пол: Мужской

« Ответ #2 : 20-09-2010 14:49 » 

Верхний слой - клиент. Это интерфейс, обработчики событий, редакция/чтение данных. При добавлении, скажем "студента" в "деканат", клиент формирует виртуальную сущность (нахватался умных слов) "студент" исходя из введенных данных (заполняет поля класса), затем передает это среднему слою.
Средний слой - оперирует сущностями - знает как их сохранить, удалить, достать по хитрому запросу. Знает, как связаться с сущностями БД (использую LinqToSQL).
Если на клиенте делать защиту "от дурака" - то нужно обращаться к среднему слою с запросом "проверь-ка номер зачетки этого студента на уникальность"?
Я просто уже пошел по другому - оператор заполняет данные, жмет "принять". Клиент на машине оператора вызывает сервис (средний слой), передает ему класс студент. Средний слой подтверждает уникальность нужных полей, в протвном случае генерит исключение, которое ловит клиент и передает оператору.
В чем разница, если делать  защиту "от дурака" на клиенте? Не будет ли размазана логика?
Записан
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 20-09-2010 15:10 » 

защита от дурака

в номере зачетки должен быть только валидный номер, например АК 12345678
ИНН код удобно проверять на клиенте
дату  проверять на валидность. или делать только через сервис календаря
выбор пола только М или Ж
Т.е. клиент должен проверять валидность данных.

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

Уникальность  пусть занимается нижний слой.


Хотя все зависит от реализации.
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4 : 20-09-2010 22:13 » 

В каком месте лучше проверять валидацию данных, заносимых в БД?

Как можно ближе к данным, как можно дальше от клиента. Если получится, то средствами СУБД. Если их окажется мало, тогда средствами среднего слоя. В самом крайнем случае - средствами клиента.

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

Впрочем, как сказал Sla, толково написанный клиент может упростить ситуацию. Например, если выбор пола на форме осуществляется радиокнопками "М" и "Ж", это лучше, чем дать возможность ввести произвольную литеру, а затем получить от сервера сообщение об ошибке. Но и в этом случае неплохо, если даже при ошибке клиента нижележащие слои сумеют отфильтровать ошибку и не пропустят заведомо дефектную транзакцию.

P.S. Если писать уж совсем корректную программу, необходимо учесть, что полов в настоящий момент известно уже не два, а четыре, и возможно появление новых. Так что дальновиднее делать выбор из списка.
« Последнее редактирование: 20-09-2010 22:49 от Dale » Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #5 : 21-09-2010 03:45 » 

про полы поподробней Улыбаюсь

на старой работе всю валидацию делал средний слой, из-за этого были определённые грабли, т.е. находился некто, который руками кривил что-нибуть в БД или ошибка в пакете закралась и тогда могло разорвать систему в непредсказуемом месте
Записан

Странно всё это....
Kivals
Команда клуба

ca
Offline Offline
Пол: Мужской

WWW
« Ответ #6 : 21-09-2010 05:29 » 

Dale, +1

Тоже считаю что проверку нужно делать максимально близко к СУБД, но для удобства работы можно дублировать и на клиенте. Пример: использование AJAX для веб-клиента, с предупреждением о неправильном значении, сразу после ввода поля, но до попытки записи в базу.

Про 4 значения пола мне тоже интересно Улыбаюсь я могу придумать или 3 - или 5, но не 4...
Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #7 : 21-09-2010 05:50 » new

про полы поподробней Улыбаюсь

Извольте Улыбаюсь

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

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

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

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines