Оптимальный способ преодоления несоответствия при хранении двух моделей домена (пользователь) с одинаковым уникальным идентификатором («имя пользователя»)

Question

При создании пользователей я хочу избежать повторяющихся имен пользователей .

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

---

Отредактировано

Кстати, яхочу поддерживать согласованность не в базе данных, а на уровне приложений.Я не хочу зависеть от конкретной базы данных.

Как вы думаете, что будет оптимальным способом решения этой проблемы?

Answer 1

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

Общий термин для того, чего вы пытаетесь достичь, это проверка правильности установки .

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

Когда вы имеете дело с уникальностью , другой возможностью является использование самого уникального свойства какпервичный ключ (либо в виде естественного ключа, либо в виде хэша), а затем напишите свои ограничения, чтобы гарантировать, что два разных пользователя не будут храниться под одним и тем же ключом.

(есть ли пользователи в вашем домененесколько адресов электронной почты? они меняют адреса?)

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

(Короче говоря, информация о моделировании, которой управляет ваша система, отличается отинформация о моделировании, которую контролирует другая система).

Answer 2

Лучше и проще обеспечить уникальность на уровне БД, но если вам абсолютно необходимо сделать это на прикладном уровне, уникальность должна быть предоставлена ​​на уровне кластера службы (между всеми запущенными экземплярами службы, поэтому работа с памятью не будетпомощь), и вам нужно решение для состояния гонки, вы можете использовать механизм распределенной блокировки.Обычно во всех экосистемах MS есть компонент, обеспечивающий функциональность блокировки в качестве службы (например, Consul), но все же это немного более сложное решение, и вместо того, чтобы быть связанным с БД, решение будет связано с службой блокировки, обеспечивающей обслуживание.

Сноваэто относится только к очень конкретным случаям и поможет избежать проблем состояния гонки при создании записей между различными экземплярами службы на уровне приложения (описанная вами проблема)

Answer 3

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

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

На человеческом уровне использование электронной почты в качестве имени пользователя часто помогает людям запомнить свое имя пользователя(а не Ako542 в одном месте и Ako392 в другом).Маловероятно, что два человека будут пытаться использовать его параллельно, поэтому маловероятно, что они увидят сообщение, созданное техническими решениями, представленными выше.