Czy ktoś z powodzeniem użył przepływu pracy systemu Windows w silniku reguł biznesowych / walidacji?

Zastanawiałem się, czy ktoś z powodzeniem użył Windows Workflow Foundation do silnika BusinessRules / Validation, czy znasz jakiś przykładowy kod lub artykuły na ten temat.

Jeśli używałeś go wcześniej, co o tym sądzisz? Jak to się ma do innych systemów BusinessRule / Validation?

Myślę o takich zasadach

if (A, B, and C) 
    AllowAccess();

Lub

if (Value between X and Y)
    return true;

Kilka miesięcy temu zacząłem budować silnik przy użyciu WWF WCF. Nie wiem, jak skomplikowana jest twoja baza reguł, ale nasza była dość duża. Gdy masz potencjał na 40 000 oddziałów, WWF nie jest dobrym rozwiązaniem. Alternatywnie skończyłem z budowaniem silnika, który korzystał z tabel wyjątków logicznych w SQL. Wiersze będą przechowywać podstawowe wartości, a także sformatowane ciągi dla formuł, które różnią się między wyjątkami. W połączeniu z dynamicznym językiem (użyłem wbudowanego silnika ironpython z otoką i można użyć wbudowanego silnika JScript), logikę można było ustalić na bardzo abstrakcyjnym poziomie w locie. Cieszę się, że wybrałem tę trasę.Logika typu „przeciągnij i upuść” wydaje się świetna, ale ludzie biznesu nigdy nie będą w stanie jej używać, pomimo marketingu, i spowolni to programistę, co szybko stanie się gniazdem szczura .

Aktualizacja: jeśli nadal jesteś zainteresowany, oto przewodnik dla początkujących . Z pewnością nie jest ekspansywny, ale ma przyzwoite filmy. Jeśli chodzi o konfigurację, nasi inżynierowie sieci wykonali konfigurację dla mnie (zasady firmy dotyczące utrzymania serwera, bezpieczeństwa itp.), Ale podobno było prawie identyczne z konfiguracją podstawowej usługi WCF. Zasadniczo wrzuć go do katalogu wirtualnego w ISS. Ponieważ jest to zwykle proces długotrwały, należy zachować szczególną ostrożność podczas zarządzania pamięcią podczas pisania usługi. Brak wyrzucania niektórych zasobów raz za razem przez 6 miesięcy naprawdę się zsumuje, a twój serwer nie będzie zadowolony.

Muszę się zgodzić z ironcode. Napisaliśmy system typu „przeciągnij i upuść” na kilka lat przed pojawieniem się nowego Biztalk (co dziwne). Chodziło o to, że nieprogramiści mogliby programować, a system byłby łatwy w utrzymaniu i zmienianiu.

Rezultat: nadal potrzebujesz „analityków biznesowych”, którzy musieliby być tak wyszkoleni jak programista, ale w nowym „języku” systemu WWF. Więc wcale tam nie zyskałeś. Debugger nie był tak dobry jak prawdziwy system programistyczny, więc przegrałeś. Potrzebowaliście także programistów do napisania trudnych modułów, które były rdzeniem przetwarzania danych i GUI. Skalowalność również wymarła bardzo szybko. Proste reguły biznesowe były łatwe do ułożenia, ale kiedy minęło tuzin, byłeś w spaghetti.

Myślę, że przyniosło to pewne korzyści, ale zasadniczo lepiej byłoby użyć silnika skryptowego do powiązania niestandardowych modułów.

Wyglądało to naprawdę fajnie dla typów marketingowych, stworzonych na świetne demo :)