Вопросы блока проверки приложения - PullRequest
Новая
       4

Вопросы блока проверки приложения

1 голос
/ 06 декабря 2009

Кто-нибудь использовал блок приложения проверки из корпоративной библиотеки? Любой успех?

В любом случае, мой вопрос касается проверки числового уникального идентификатора. Допустим, у меня есть класс Product со свойством ProductId, представляющим уникальный идентификатор продукта. Это числовое. Этот идентификатор не может быть меньше 1, он должен быть больше 1. Я не знаю, какой тип проверки выбрать, используя блок приложения проверки. Я думал о том, чтобы попробовать тип диапазона, но для этого нужно 2 значения: нижнее и верхнее.

Еще один вопрос к проверке свойств бизнес-объекта. Это лучший способ проверить бизнес-объекты? Я хочу указать правила проверки только один раз, а затем использовать их на разных уровнях, например ASP.NET. Я никогда не проверял бизнес-объекты таким образом, только на стороне клиента. Может кто-нибудь сказать мне, по какому маршруту лучше всего идти, и если я в правильном направлении?

Может кто-нибудь посоветовать?

Спасибо Брендан

Ответы [ 2 ]

2 голосов
/ 07 декабря 2009

VAB Experience

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

Проверка числового уникального идентификатора

Вы на правильном пути с валидатором диапазона. Имейте в виду, что каждый диапазон (верхний и нижний) может иметь 3 различных типа: включительно, исключительно и игнорировать. Это должно охватывать большинство случаев. В вашем случае вы можете указать верхнюю границу как игнорирующую, а нижнюю - как 1 включительно (если вы хотите, чтобы ProductId был 1 или больше).

В конфигурации это будет выглядеть так: 

   <properties>
      <property name="ProductId">
        <validator lowerBound="1" lowerBoundType="Inclusive" upperBound="0"
          upperBoundType="Ignore" negated="false" messageTemplate="Oops...too low." messageTemplateResourceName=""
          messageTemplateResourceType="" tag="" type="Microsoft.Practices.EnterpriseLibrary.Validation.Validators.RangeValidator, Microsoft.Practices.EnterpriseLibrary.Validation, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
          name="Range Validator" />
      </property>
    </properties>

Проверка свойств бизнес-объекта

Звучит так, как будто вы на правильном пути. Вы обязательно должны всегда проверять входные данные для своего бизнес (или сервисного) уровня. Если вы также хотите выполнить проверку на уровне клиента, то вы можете совместно использовать свою конфигурацию или сущности (бизнес-объекты, как вы их называли) между уровнями, но вы должны будете убедиться, что конфигурация или сущности синхронизированы между уровнями. Еще одна вещь, которую следует учитывать, если вы проводите проверку на двух разных уровнях, это то, как будут отображаться результаты ValidationResults. VAB имеет интеграцию с ASP.NET, но как только вы вызовете бизнес-уровень, у вас не будет такой интеграции, поэтому вам потребуется другой (настраиваемый) способ отображения этих ошибок. (Это может быть так же просто, как метка, чтобы сбросить ошибки).

Теперь вы говорите: ах, но если я проверил на веб-уровне, я должен отловить все ошибки валидации в ASP.NET, и все это прекрасно работает вместе. Правда. Но это подводит меня к моему последнему пункту.

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

0 голосов
/ 06 декабря 2009

Почему бы не установить верхнюю границу валидатора равной максимальному значению любого типа, с которым вы работаете?

Например, если вы используете Int32, сделайте следующее: 

[RangeValidator(1, RangeBoundaryType.Inclusive, 
Int32.MaxValue, RangeBoundaryType.Inclusive)]

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

...