AndryGПишу код уровня "доступа к даным", При повторном прогоне кода создания юзера вылезла ожидаемая ошибка уникальности логина. Тут и появилась мысль использовать это для уменьшения кода валидаторов - не делать некоторые и вылавливать для этого ошибки БД.

все верно, проверка уникальности/ссылочной целостности и должны производится только на уровне БД т.к. на клиенте такие проверки бессмысленны и вредны, валидация бизнес-логики включает в себя по-сути 3 шага
а) На клиенте для удобства пользователя (формат email'a, длина строки итд)
б) Дубликат всех этих проверок на аппсервере плюс дополнительная валидация общих бизнес-правил (лимит не превышен, безопасность итд)
в) Дубликат части либо всех этих правил в БД (формат email'a, длина строки, лимиты) плюс ограничения уникальности/ссылочной целостности.

Ошибки уникальности/ссылочной целостности идущие из БД отлавливаются и выводятся соответствующие сообщения юзеру, остальные ошибки логируются для последующего изучения

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

тебя забанить надо козленок, за оскорбления и весь тот бред, который ты несешь на проффорумах людям, которые просят профессионального совета

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

какие еще аргументы, почему за FindUserByLogin() для определения уникальности ты получишь хороших люлей на code review? Нет, тебе никаких аргументов не будет, читай документацию, оторви свой профуровень от плинтуса для начала

все говно вышло? Каждый раз когда тебя в лужу сажают одна и та-же реакция...

вот за свой базар это ты как раз не привык похоже отвечать, в реале ты-б за малую толику тех оскорблений и дерьма вылитых в этом топике ты-б зубы собирал по всему полу

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

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

Плюс регистрация вполне может оказаться визардом в N шагов с прикреплением скана документа, подтверждающего личность.
И запись в целевую таблицу происходит только после его прохождения и ещё каких-то проверок.
И как-то нелепо после всего сообщать пользователю, что такой логин уже занят, опираясь на ошибку о нарушении уникальности.

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