Если приложение должно быть многопользовательским (т. Е. Не просто одно настольное приложение с одним пользователем, а централизованной БД с приложением, действующим в качестве клиентов, может быть, на многих рабочих станциях), то полагаться наклиент (приложение) для проверки таких, как уникальность, существование, свободные номера и т. д., поскольку существует явная возможность изменения, происходящего между вызовами (если не используется блокировка чтения, но это часто становится скорее проблемой, чем помощью!).
Существует возможность, конечно, предварительно проверить и затем перепроверить (предварительно на уровне приложения, повторно в БД), но, конечно, это даст дополнительный трафик БД, поэтому зависит от того, является ли это проблемой для вас.
Когда я пишу SPROC, которые будут возвращаться в приложение, я всегда использую одну и ту же структуру - я включаю параметры для кода возврата и сообщения и всегда заполняю их.Затем я могу использовать стандартные процедуры для их вызова и даже автоматически добавлять параметры.Затем я могу либо отобразить сообщение непосредственно при ошибке, либо использовать код возврата, чтобы локализовать его по мере необходимости (или автоматизировать ответ).Я знаю, что некоторые БД (например, SQL Svr) будут возвращать параметры Return_Code, но я использую свои собственные, чтобы оставить встроенные для серьезных системных ошибок и неожиданных сбоев.Также позволяет мне иметь собственные системы нумерации для кодов возврата (то есть группировать их в соответствии с перечислениями в коде и / или группировать по серьезности)
В веб-приложениях я также иногда использовал другую концепцию.Например, иногда делается запрос на новую учетную запись, но требуется несколько страниц (например, профиль).Здесь я часто использую таблицу заголовков, которая генерирует скрытый идентификатор пользователя для запрошенного уникального имени пользователя, временную метку и в некотором роде их распознавание (IP-адрес и т. Д.).Если по истечении x часов он не используется, таблица заголовков удаляет строку, освобождая номер (в зависимости от БД номер может никогда больше не стать пригодным для использования - это не имеет значения, поскольку используется только для сохранения уникальности пользовательских данных до применения.отправлено) и имя пользователя.Если все выполнено правильно, то записи просто копируются в соответствующие активные таблицы.
// Правка - Добавить:
Хороший вопрос.Но уникальность аккаунта - это очень маленький простой пример.А как насчет более сложных требований к учетным записям в бизнес-логике?Например, если я реализую только в клиентском коде (в приложении winforms), у меня все будет хорошо, но если я хочу, чтобы другой (скажем, консольная версия моего приложения или веб-сайт) вида моего приложения работал с этими учетными записями, я должен сделать все этологика снова в новом приложении!Итак, я ищу какой-то метод для хранения данных с двух сторон (серверная база данных и клиентская сторона).- kseen вчера
Если требование mutiuse всегда, то лучше его отделить.Помещение его в отдельный проект библиотеки классов позволяет использовать DLL-библиотеку вашей WinForm, консольной программой, службой и т. Д. Хотя я бы все же предпочел валидацию (уровень БД), так как это наиболее близкий момент времени к любому действию и минимумскорее всего, gazzumped.
Обычный способ - разделить на три проекта.Слой отображения [DL] (ваш winform-проект / консоль / служба / и т. Д.) И уровень бизнес-приложений [BAL] (который содержит все бизнес-правила и обращения к DAL - он ничего не знает ни о среде diplay, ни о технологии базы данных)и, наконец, уровень доступа к данным [DAL] (здесь есть все вызовы базы данных - он может быть очень простым с методом вставки / обновления / выбора / удаления на уровне SQL и SPROC и, возможно, с некоторыми классами для передачи данных туда и обратно).DL ссылается только на BAL, который ссылается на DAL.DAL может быть заменен для каждой технологии (скажем, изменение с SQL Server на MySQL), не затрагивая остальную часть приложения, и бизнес-правила могут быть изменены и установлены в BAL без влияния на DAL (DL может быть затронут, если новые методыдобавлено или отображено изменение требований из-за изменения данных и т. д.).Затем этот фреймворк можно использовать снова и снова во всех ваших приложениях, и в него легко внести довольно радикальные изменения (например, топология БД).