#c# #asp.net #rules #business-rules #rule-engine
#c# #asp.net #Правила #бизнес-правила #движок правил
Вопрос:
В настоящее время я пишу .net-приложение на c # и хочу проверить ряд правил и на основе прохождения или невыполнения правил выполнить действие. Итак, я ищу универсальное решение, которое я мог бы повторно использовать, придерживаясь хороших принципов ооп. Это привело меня к выводу, что мне нужно написать движок правил.
Я хорошо разбираюсь в c #, но это первый раз, когда мне понадобилось написать движок правил, поэтому в рамках моего исследования в области проектирования и разработки такого движка я ищу любые советы относительно создания такого движка. Что было бы еще замечательным, были бы какие-нибудь примеры, на которые я мог бы посмотреть? Есть какие-либо приложения движка правил c # / .net? На каком уровне типичной трехуровневой архитектуры это должно находиться? Я быстро просмотрел codeplex и Google code, но ни один из них не бросился мне в глаза! Так что какое-то направление было бы здорово.
Ответ №1:
На самом деле .Сетка имеет первоклассный правила двигателем предназначены для использования с рабочими процессами (так как он предназначен, чтобы быть), но может использоваться вне рабочие процессы легко: вы должны увидеть «процесс Windows правил фонда двигателя» и проверьте систему.Рабочий процесс.Действия.Пространство имен Rules.
Для изучения того, как использовать правила вне рабочих процессов, требуется всего лишь немного поискать в Google.
Редактировать: Если вы хотите ознакомиться с архитектурой, вот два готовых движка с открытым исходным кодом:
Комментарии:
1. Я знаю, это звучит как ужасное высокомерие, но я обнаружил, что библиотека правил WF анемична и практически непригодна для использования по сравнению с хорошо разработанным, настроенным движком, зависящим от домена. Конечно, это действительно зависит от приложения, но я не знаю, буду ли я так быстро рекомендовать это.
2. Я постоянно использую его в своих рабочих процессах для медленно развивающихся приложений промышленного управления, что создало у меня впечатление, что это одна из самых прагматичных реализаций. Но, может быть, это потому, что я так хорошо с этим знаком. Но я знаю, что это больше похоже на типичный аргумент xUnit против MSUnit..
3. Возможно. Все, что я знаю, это то, что каждый раз, когда я пытался использовать WF (или правила WF), я всегда заканчивал тем, что разводил руками и говорил: «Почему бы мне просто не написать код вместо того, чтобы втискивать его в эту штуку?» Я не сравниваю WF с другими движками документооборота, я уверен, что все они хороши, я думаю, что я хочу сказать, что большинство, если не все, движки правил OTS слишком универсальны, чтобы предложить много преимуществ по сравнению с простым кодом конфигурация. Возможно, это просто моя неопытность / неудачный опыт.
Ответ №2:
Создание и реализация вашего собственного движка правил может быть очень сложной задачей, требующей учета многих факторов. Самая большая проблема, с которой вы столкнетесь, — это попытка решить, какие правила запускать и когда. Отсутствие должного внимания к этому может привести к проблемам с производительностью в рамках реализации. Я бы настоятельно рекомендовал сосредоточиться на бизнес-задаче и предоставить вашим экспертам в предметной области (SME) возможность определять и поддерживать свои собственные правила. Есть много хороших коммерческих продуктов, которые делают это; тот, который я успешно реализовал несколько раз, это www.inrule.com . У них есть хороший набор продуктов, которые могут помочь решать простые и сложные проблемы. Надеюсь, это поможет.