Это очень важно, каковы ваши точные требования. «Быть гибким» само по себе не является хорошим требованием, потому что оно не поддается измерению. Это очень субъективно, если что-то гибкое.
Я не знаком с Microsoft Business Rules Engine, поэтому не могу комментировать это. Тем не менее, я очень хорошо знаком с блочным приложением валидации Microsoft Enterprise Library (VAB), и оно хорошо мне помогло за последний год. Он имеет несколько функций, которые делают его гибким для ситуаций, с которыми я сталкиваюсь:
- Это позволяет как определять декларативную проверку (используя атрибуты), так и использовать внешний файл конфигурации (что очень полезно при создании ваших сущностей).
- Он содержит набор валидаторов по умолчанию, которые можно использовать, и можно написать собственные валидаторы.
- Позволяет проверять отдельные свойства и позволяет сравнивать несколько свойств как группу (с помощью самопроверки или пользовательских валидаторов).
- Позволяет проверять как объекты, так и графы объектов.
- Он позволяет вам определять несколько «наборов правил», которые, например, позволяют вам определить набор серьезных ошибок и набор предупреждений.
VAB (или Корпоративная библиотека в целом) позволяет вам написать собственный источник конфигурации (IConfigurationSource), который позволяет вам определять ваши бизнес-правила в любом месте. Таким образом, теоретически вы можете хранить их в базе данных, однако вам придется написать такой источник конфигурации самостоятельно, и это будет довольно трудоемко. Особенно, когда вы хотите, чтобы ваши бизнес-аналитики могли определять валидации и обновлять базу данных с помощью какого-либо инструмента редактирования, они думают, что это будет весьма адски с VAB.
Если деловым людям действительно необходимо написать эти правила самостоятельно, надеюсь, у вас есть процесс, поддерживающий это требование. Например, как они собираются проверить, правильны ли их изменения? Вам не нужно, чтобы ваши бизнес-аналитики вносили изменения непосредственно в производственную базу данных.
Но, пожалуйста, подумайте об этом. Если правила будут проверены, я ожидаю, что эти правила не будут изменены непосредственно в вашей производственной базе данных, в противном случае вы будете тестировать после факта. Таким образом, аналитики будут изменять правила в своей собственной среде, и вы, вероятно, будете публиковать новые правила из этой среды в тестовую среду, а затем в среду принятия и в конечном итоге в производственную среду. И если вы предпринимаете эти шаги, следует ли вам использовать базу данных для хранения этих бизнес-правил? Использование файла конфигурации сделало бы это намного проще, чем использование базы данных. Развертывание будет просто копией файла, а не копированием содержимого нескольких таблиц из базы данных в базу данных.
Мне интересно, что другие скажут о хорошо знакомых им структурах валидации.