База данных имеет уникальный индекс ограничения для поля пользователя NAME.
Бизнес-сервис проверяет через
service.GetUser(userName);
чтобы увидеть, существует ли уже имя пользователя. Из-за этой логики в сервис никогда нельзя вставлять повторяющиеся имена. Я не улавливаю исключения для SqlException с номером = 2627, что связано с уникальными нарушениями ограничений.
Так зачем мне накладывать уникальное ограничение на поле NAME?
Из-за этой логики в сервис никогда нельзя вставлять повторяющиеся имена, так ЗАЧЕМ мне ставить в поле NAME уникальное ограничение?
Потому что нет другого хорошего способа гарантировать, что в течение всего времени существования базы данных ни одно приложение не будет добавлять данные, кроме как через эту службу.
Каждая СУБД, с которой я знаком, включает в себя интерфейс командной строки, графический интерфейс и массовый загрузчик. Таким образом, получается по крайней мере три приложения, которые можно использовать для изменения данных без использования service.GetUser().
Вы должны разместить как можно больше бизнес-логики на уровне данных. Отношения, уникальность, длина, минимальная длина, ограничения значения, все, что вы можете.
Не доверяйте приложению правильно вводить их, пользователи ваших данных попытаются сломать их любым возможным способом. Я лично считаю, что лучше отправить 500 с неверными данными, чем принять их и исправить позже, хотя некоторые люди скажут вам обратное, поскольку это очень спорный вопрос.
Удачи.
Установка ограничения UNIQUE на уровне базы данных гарантирует отсутствие повторяющихся имен независимо от того, где находится точка входа вставки (или обновления). Например, если вы предоставите прикладному уровню возможность обеспечить уникальность имен, что произойдет, если кто-то вставит строку непосредственно из командной строки или пакетного сценария вне области приложения?
ИМО, лучше сохранить это уникальное поведение ограничения на уровне базы данных.
