Правила валидации и валидации для веб-сервисов

Я испытал следующий сценарий в большинстве приложений веб-сервисов, над которыми я работал:

  1. Мы создаем модель домена (на C #). Это сердце приложения. Модель предметной области содержит бизнес-правила и правила проверки, которые определяют, при каких условиях объект действителен или нет.
  2. Мы создаем слой «веб-службы» (в C # / WCF). Этот уровень определяет объекты, подобные DTO, которые предоставляются веб-службами. Объекты, подобные DTO, нарезаются и собираются из частей сущностей домена, как правило, крупнозернистым способом.
  3. В веб-клиенте (JavaScript и HTML) правила проверки дублируются в другом формате, обычно это некоторая форма проверки JavaScript.

Каким образом правила проверки, прикрепленные к частям объектов домена, могут быть представлены клиенту через веб-службы? Причина этого в том, что правила проверки модели предметной области должны быть определены один раз, а затем быть доступны клиентам-потребителям в некотором формате во всей остальной системе.

Единственное решение, которое я придумал до сих пор, - это сделать правила проверки из домена доступными в какой-либо форме метаданных, определенных в XML, JSON или аналогичных. Большая проблема заключается в том, что схемы между DTO уровня сервиса и объектами домена различаются, и поэтому правила проверки домена не могут быть напрямую отправлены веб-клиенту - клиент работает с другой схемой и моделью домена.

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


javascript validation c# web-services domain-driven-design
person J du Preez    schedule 24.06.2011    source источник
comment
Почему бы просто не сериализовать объекты домена, а не создавать разные DTO с разными правилами проверки? Если вы не хотите изменить объекты домена, но оставить уровень обслуживания таким же, я не вижу, что добавляет это преобразование.   -  person Ben Robinson    schedule 24.06.2011
comment
Существует множество причин для определения сервисных DTO. Клиенты пользовательского интерфейса, использующие службу, имеют другие требования к схеме, чем домен. В REST вы будете определять и передавать REST-ресурсы. С сущностями домена прикреплено множество вещей, которые не имеют значения для обслуживания клиентов. Это соответствует лучшим практикам SOA ... и т. Д. И т. Д.   -  person J du Preez    schedule 24.06.2011
comment
Интересно, что я бы считал уровень обслуживания сердцем приложения, потому что он определяет доступную информацию и доступные функции. Извините, но у меня нет ответа на ваш вопрос. Сначала я подумал о OCL (языке объектных ограничений), но об этом я только слышал.   -  person Kwebble    schedule 24.06.2011

Ответы (1)


arrow_upward
0
arrow_downward

Есть два типа бизнес-правил:

Специальные правила для приложений

Особые правила домена.

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

Например, я использую ViewModel в своем веб-приложении, которое украшено атрибутами проверки, облегчающими ненавязчивую проверку на стороне клиента через jQuery.

Я использую AutoMapper для преобразования объекта домена в модель просмотра и наоборот.

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

person BonyT    schedule 24.06.2011
comment
Пожалуйста, объясните, например, как вы можете сообщить своему клиентскому и сервисному слою, что в вашем доменном объекте Person определено FirstNameMandatoryValidatioRule, без необходимости вручную переопределять / перекодировать его в вашей ViewModel? Другими словами, в идеале я ищу решение, в котором я могу обновить FirstNameMandatoryValidationRule в домене, а сервисные DTO и веб-клиент должны иметь возможность автоматически знать, что все, что это поле вызывается в его схеме, является обязательным. Правила валидации следует определять только один раз, остальная система должна просто их интерпретировать. - person J du Preez; 24.06.2011
comment
Также веб-клиент (ViewModel в вашем случае) должен иметь возможность выполнять проверку локально, без вызова службы и домена. - person J du Preez; 24.06.2011
comment
Правила валидации следует определять только один раз, остальная система должна просто их интерпретировать. Я не согласен с этим утверждением. Проверка на уровне домена должна быть контролирующей, а не диктующей. Если существует возможность повторного использования, это следует учитывать - например, Связывание пользовательского интерфейса с открытыми объектами домена, а не с DTO, но TBH это настолько ограничивает в других отношениях, что в большинстве случаев оно того не стоит. Здесь, вероятно, есть и другие мнения, и я согласен, что не дал вам ответа, который вы искали - возможно, просто пища для размышлений. - person BonyT; 24.06.2011
comment
Веб-клиент должен выполнять проверку локально. Затем это дважды проверяется в веб-службе, которая работает с базой данных (веб-приложение не имеет прямых подключений к базе данных - только к службам WCF). Веб-приложение должно проверять себя по соображениям производительности. Служба WCF также должна пройти проверку, поскольку это смысл существования - защита достоверности данных. - person BonyT; 24.06.2011
comment
Примечание - статья, в которой не рекомендуется привязывать напрямую к объекту домена - codethinked.com/ aspnet-mvc-think-before-you-bind - person BonyT; 24.06.2011
comment
Еще одна вещь, о которой стоит подумать - если вы все еще не уверены: допустим, вы успешно нашли метод достижения того, что пытаетесь сделать. Затем вас попросят создать еще одного клиента для Сервиса с другими требованиями, и проверка будет другой. Как бы вы справились с этим? Будет ли проверка по-прежнему выполняться внутри службы, но делать ее контекстно-зависимой, т. Е. Знать, кто ее использует и какую проверку следует применить? Или вы оставите клиенту СКАЗАТЬ сервису, какие именно этапы проверки он должен выполнять? - person BonyT; 25.06.2011
comment
BonyT. Спасибо за подробное обсуждение. Определенно пища для размышлений. Просто чтобы убедиться, что все понимают. Я не хочу привязывать к домену. Я хочу, чтобы домен мог выражать * свои бизнес-правила, связанные с действительностью его объектов. Я хочу, чтобы разные клиенты пользовательского интерфейса могли понимать эти правила и переводить их в понятный формат. Важно то, что правила должны быть определены один раз, а различные клиентские объекты (пользовательский интерфейс и веб-службы), использующие модель предметной области, должны иметь возможность понимать и переводить правила. - person J du Preez; 27.06.2011