Что бы вы использовали для уровня проверки бизнеса? - PullRequest
12 голосов
/ 08 февраля 2009

В моем проекте мне нужно создать слой проверки бизнес-объектов, который возьмет мой объект и запустит его в соответствии с набором правил и вернет либо «пропущено», либо «нет», а также список причин ошибок. Я знаю, что для этого есть немало вариантов.

От Microsoft:

Открытый исходный код:

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

Редактировать: Я не просто спрашиваю о общей длине строки проверки <200, почтовый индекс 5 цифр или 5 + 4, но предполагаю, что механизм правил будет фактически задействован. </p>

Ответы [ 9 ]

6 голосов
/ 09 февраля 2009

Решение «код против правил» - это вопрос компромиссов, ИМХО. Вот несколько примеров:

Преимущества кода

  • Потенциально более высокая производительность.
  • Использует существующие навыки разработчиков.
  • Нет необходимости в отдельных инструментах, двигателях времени выполнения и т. Д.

Преимущества правила двигателя

(Функции различаются в зависимости от различных механизмов правил.)

  • Правило DSL, доступное для записи (или, по крайней мере, для чтения) бизнес-пользователями.
  • Свойства даты вступления в силу и срока действия, которые позволяют автоматически планировать правила.
  • Гибкая отчетность из репозитория правил поддерживает улучшенный анализ и аудит поведения системы.
  • Подобно тому, как механизмы базы данных изолируют проблемы содержимого / взаимосвязи данных от остальной системы, механизмы правил изолируют проверку и политику от остальной части системы.
5 голосов
/ 14 февраля 2009

Модифицированная версия правил структуры CSLA.

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

Bahh. Очень немногие пользователи собираются изучать сложности формата документа правил или понимать сложности и последствия их изменений.

Другое обещание заключается в том, что вы можете изменить правила без необходимости изменения кода. Я так говорю что? Изменение правила, даже такого простого, как «это поле не должно быть пустым», может оказать очень негативное влияние на приложение. Если те поля, где раньше было разрешено быть пустыми, теперь у вас есть куча неверных данных в хранилище данных. Кроме того, современные приложения основаны либо на веб-технологиях, либо распространяются / обновляются с помощью таких технологий, как клик = один раз. Таким образом, обновить пару компонентов так же просто, как обновить файл правил.

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

3 голосов
/ 08 февраля 2009

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

После нескольких итераций проект, наконец, перешел в Open Source (лицензия BSD) и оказался полезным в производственных системах. Основные функции .NET Application Block для проверки и бизнес-правил :

  • Просто начать работу с
  • Правила для доменных объектов
  • Правило многократного использования
  • Предопределенные правила проверки
  • Расширяемость поведения
  • Правильное размещение объектов
  • Предназначен для проверки уровня DDD и пользовательского интерфейса
  • Несколько уровней отчетности
  • Производственная и активная разработка
  • Маленькая кодовая база
  • Открытый исходный код

Вот как выглядит простое связывание правил на уровне пользовательского интерфейса:

Binding Rules to UI

Обратите внимание, что в текущей реализации нет DSL в данный момент. Синтаксис C # сам по себе достаточно выразителен, поэтому не было необходимости добавлять поверх DSL на основе Boo.

2 голосов
/ 08 февраля 2009

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

1 голос
/ 16 марта 2012

Попробуйте

http://rulesengine.codeplex.com

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

Больше не надоедать валидацию в стиле атрибутов - чем вы не владеете, тем классом, который хотите валидировать

Имеется плагин для Asp.Net MVC (только на стороне сервера).

Существует также еще один проект под названием Polymod.Net , который использует RulesEngine для предоставления самопроверяющихся пользовательских интерфейсов, как показано на снимке экрана!

1 голос
/ 15 февраля 2009

Если вы заинтересованы в том, чтобы катиться самостоятельно, прочитайте пост JP Boodhoo об обработке правил По сути, он излагает прямую основу для проверки объектов домена.

Проверка на уровне домена

Проверка на уровне домена 2

1 голос
/ 12 февраля 2009

Я экспериментировал с Workflow Foundation, использовал EntLib и написал свой собственный движок правил.

В небольших приложениях, где мне действительно нужно выполнять проверку на основе пользовательского интерфейса, чтобы убедиться, что недопустимые данные не проникают в БД, я достигаю блока проверки EntLib. Он прост в использовании и требует лишь минимального количества кода в объектах моего домена, плюс он не портит NHibernate или что-либо еще в моем технологическом стеке.

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

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

0 голосов
/ 12 февраля 2009

Я рекомендую использовать CSLA Framework . Не только для проверки, но и для других функций.

0 голосов
/ 08 февраля 2009

Блок валидации Enterprise Library обеспечивает очень похожий на AOP подход и позволяет легко разобраться в версиях 3.1 и 4.1 из моего опыта.

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