Валидация данных перед внесением в БД

[yudjin]

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

[Sla]

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

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

[yudjin]

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

[Sla]

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

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

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

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


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

[Dale]

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

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

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

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

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

[Антон (LogRus)]

про полы поподробней

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

[Kivals]

Dale, +1

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

Про 4 значения пола мне тоже интересно я могу придумать или 3 - или 5, но не 4...

[Dale]

про полы поподробней

Извольте

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

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

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