MVC, где поставить проверку, которая требует вызова БД

Question

Возьмем этот простой, общий сценарий в приложении mvc:

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

Теперь я много читал о структуре проекта, управляемой доменомдизайн, валидация, mvc и т. д., и я доволен своими логическими уровнями: домен (модель, ядро), доменные службы, контроллеры и представления.Например, я могу убедиться, что имя пользователя содержит менее 10 символов, добавив атрибут проверки в мое свойство.Отказы будут пузыриться обратно через сервисный уровень в контроллер и выходить в представление.

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

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

Вау!Доменный объект, вызывающий БД напрямую ??Я не уверен, что это плохо.Я могу сделать так, чтобы Castle вводил IRespositories в домен, верно, поэтому нет жесткой связи, и в конце концов это домен, который определяет интерфейсы данных.

У кого-нибудь есть опыт / мнения по этому поводу?

Answer 1

Для меня это все еще проблема проверки модели User.

Неверно ... Конечно, нет.Пользователь не должен знать о братьях и сестрах.

Если Пользователь является сущностью (которой он, безусловно, не является), проверка уникальности является обязанностью содержать совокупный корень.

Если это совокупный корень,вариантов не так много (потому что «ничто не держит» совокупного корня, они глобальные) - для этого я использую репозитории, несмотря на то, что у них не должно быть логики домена.но опять же - я не считаю такой вид проверки уникальности действительно ценным (см. «Все правила не созданы равными»).

Answer 2

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

Последние сборки архитектуры S # arp включалиновый атрибут проверки класса HasUniqueDomainSignature, используемый вместе с атрибутом свойства DomainSignature.При вызове IsValid в NHibernate.Vaidator общий локатор службы используется для определения местоположения текущего сеанса NHibernate и ссылки на постоянство.

Здесь обсуждается .

Answer 3

Если вы собираетесь использовать DDD-маршрут, возможно, вам следует рассмотреть возможность использования команд для инициирования изменений домена.Тогда доменные объекты не будут нуждаться в проверке: вы можете выполнить всю необходимую проверку по команде.

Что касается проверки на основе атрибутов, которую предоставляют некоторые платформы (например, asp.net mvc), я действительноненавижу это.Ваша модель домена не должна быть их заботой.Доменные объекты всегда должны быть в допустимом состоянии и сами сохранять свои инварианты.