Mam całkiem przyzwoitą listę zalet korzystania z silnika reguł, a także kilka powodów, aby ich używać, potrzebuję listy powodów, dla których NIE powinieneś używać silnika reguł
Najlepsze, jakie do tej pory mam, to:
Mechanizmy reguł nie są tak naprawdę przeznaczone do obsługi przepływu pracy lub wykonywania procesów, podobnie jak silniki przepływu pracy lub narzędzia do zarządzania procesami przeznaczone do wykonywania reguł.
Jakieś inne ważne powody, dla których nie powinieneś ich używać?
rule-engine
BlackTigerX
źródło
źródło
Odpowiedzi:
Bardzo się denerwuję, gdy widzę ludzi używających bardzo dużych zestawów reguł (np. Rzędu tysięcy reguł w jednym zestawie). Dzieje się tak często, gdy silnik reguł jest singletonem znajdującym się w centrum przedsiębiorstwa w nadziei, że przestrzeganie reguł DRY sprawi, że będą dostępne dla wielu aplikacji, które ich wymagają. Przeciwstawiłbym się komukolwiek, kto powiedziałby mi, że silnik reguł Rete z tak wieloma regułami jest dobrze zrozumiany. Nie znam żadnych narzędzi, które mogą sprawdzić, czy konflikty nie istnieją.
Myślę, że zestawy reguł partycjonowania, aby były małe, są lepszym rozwiązaniem. Aspekty mogą być sposobem na udostępnienie wspólnego zestawu reguł dla wielu obiektów.
Wolę prostsze, bardziej oparte na danych podejście, gdy tylko jest to możliwe.
źródło
Podam 2 przykłady z własnego doświadczenia, w których użycie silnika reguł było złym pomysłem, może to pomoże: -
Lekcja : Nie bez powodu nazywane są one „Regułami biznesowymi”. Nie używaj reguł, gdy nie możesz zaprojektować systemu, który może być łatwo utrzymywany / zrozumiały dla użytkowników biznesowych.
Lekcja : Wymagania często się zmieniają podczas początkowych zmian w wydaniu i nie gwarantują użycia reguł. Użyj reguł, gdy Twoja firma często się zmienia (nie wymagania). Np .: - Oprogramowanie, które oblicza Twoje podatki, będzie się zmieniać co roku, gdy zmieniają się przepisy podatkowe, a stosowanie reguł to doskonały pomysł. Wersja 1.0 aplikacji internetowej będzie się często zmieniać, gdy użytkownicy będą identyfikować nowe wymagania, ale z czasem będzie się stabilizować. Nie używaj reguł jako alternatywy dla wdrażania kodu. Wcześniejsze
źródło
Jestem wielkim fanem silników reguł biznesowych, ponieważ mogą one znacznie ułatwić Ci życie jako programista. Jednym z pierwszych doświadczeń, jakie miałem podczas pracy nad projektem hurtowni danych, było znalezienie procedur składowanych zawierających skomplikowane struktury CASE rozciągające się na całe strony. Debugowanie było koszmarem, ponieważ bardzo trudno było zrozumieć logikę stosowaną w tak długich strukturach CASE i określić, czy masz nakładanie się reguły na stronie 1 kodu z inną ze strony 5. Ogólnie ponad 300 takich reguł osadzonych w kodzie.
Kiedy otrzymaliśmy nowe wymaganie dotyczące rozwoju czegoś, co nazywa się Accounting Destination, które obejmowało obsługę ponad 3000 reguł, wiedziałem, że coś musi się zmienić. Pracowałem wtedy nad prototypem, który później stał się rodzicem tego, co teraz jest silnikiem Custom Business Rule, zdolnym do obsługi wszystkich standardowych operatorów SQL. Początkowo używaliśmy Excela jako narzędzia do tworzenia treści, a później stworzyliśmy aplikację ASP.net, która pozwoli użytkownikom biznesowym definiować własne reguły biznesowe bez konieczności pisania kodu. Teraz system działa dobrze, z bardzo małą liczbą błędów i zawiera ponad 7000 reguł obliczania tego miejsca docelowego księgowania. Nie sądzę, by taki scenariusz był możliwy po prostu na sztywno.
Jednak takie podejście ma pewne ograniczenia:
Więcej szczegółów na ten temat można znaleźć w poście, który napisałem: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx
Ogólnie rzecz biorąc, największą zaletą korzystania z silników reguł biznesowych jest to, że pozwala użytkownikom odzyskać kontrolę nad definicjami reguł biznesowych i tworzeniem treści, bez konieczności udawania się do działu IT za każdym razem, gdy muszą coś zmienić. Zmniejsza również obciążenie pracą zespołów programistów IT, które mogą teraz skupić się na tworzeniu rzeczy o większej wartości dodanej.
Twoje zdrowie,
Nicolae
źródło
Jedyny punkt, który zauważyłem jako „miecz obosieczny”, to:
Widziałem, jak to działa świetnie, gdy masz jednego lub dwóch multidyscyplinarnych geniuszy po stronie nietechnicznej, ale widziałem również brak techniki prowadzący do nadęcia, większej liczby błędów i ogólnie 4x kosztów rozwoju / utrzymania.
Dlatego musisz poważnie rozważyć swoją bazę użytkowników.
źródło
Myślałem, że artykuł Alexa Papadimoulisa był dość wnikliwy: http://thedailywtf.com/articles/soft_coding.aspx
Nie jest to wyczerpujące, ale ma kilka dobrych punktów.
źródło
WIELKI artykuł o tym, kiedy nie używać silnika reguł ... (a także kiedy go używać) ....
http://www.jessrules.com/guidelines.shtml
Inną opcją jest to, że jeśli masz liniowy zestaw reguł, które mają zastosowanie tylko raz w dowolnej kolejności, aby uzyskać wynik, jest stworzenie świetnego interfejsu i poproszenie programistów o napisanie i wdrożenie tych nowych reguł. Zaletą jest to, że jest niesamowicie szybki, ponieważ normalnie przechodziłbyś sesję hibernacji LUB sesję jdbc, a także wszelkie parametry, dzięki czemu masz dostęp do wszystkich danych aplikacji, ale w efektywny sposób. Z listą faktów może istnieć wiele zapętleń / dopasowań, które naprawdę mogą spowolnić system ..... To kolejny sposób na uniknięcie silnika reguł i możliwość dynamicznego wdrażania (tak, nasze świetne reguły zostały wdrożone w baza danych i nie mieliśmy rekursji ... albo spełniła regułę, albo nie). To tylko kolejna opcja… och i jeszcze jedna korzyść to brak nauki składni reguł dla przyszłych programistów.
To naprawdę zależy od twojego kontekstu. Silnik reguł ma swoje miejsce, a powyższa opcja to tylko kolejna opcja, jeśli masz w projekcie reguły, które możesz chcieć wdrożyć dynamicznie w bardzo uproszczonych sytuacjach, które nie wymagają silnika reguł.
Zasadniczo NIE używaj silnika reguł, jeśli masz prosty zestaw reguł i zamiast tego możesz mieć fajny interfejs ..... tak samo dynamicznie wdrażalny, a nowi programiści dołączający do twojego zespołu mogą nauczyć się go szybciej niż języka ślinek. (Ale to jest moja opinia)
źródło
Z mojego doświadczenia wynika, że silniki reguł działają najlepiej, gdy są spełnione następujące warunki:
Jeśli brakuje którejkolwiek z tych czterech cech, nadal może się okazać, że silnik reguł działa dla Ciebie, ale za każdym razem, gdy próbuję go z brakiem choćby jednej, mam kłopoty.
źródło
To z pewnością dobry początek. Inną rzeczą w przypadku silników reguł jest to, że niektóre rzeczy są dobrze zrozumiane, deterministyczne i proste. Potrącenie z listy płac jest (lub powinno być) takie. Możesz to wyrazić jako reguły, które zostaną rozwiązane przez silnik reguł, ale możesz wyrazić te same reguły, co dość prosta tabela wartości.
Tak więc silniki przepływu pracy są dobre, gdy wyrażasz długoterminowy proces, który będzie miał trwałe dane. Silniki reguł mogą robić podobne rzeczy, ale musisz zrobić dużo dodatkowej złożoności.
Silniki reguł są dobre, gdy masz skomplikowane bazy wiedzy i potrzebujesz wyszukiwania. Silniki reguł mogą rozwiązywać skomplikowane problemy i mogą być szybko dostosowywane do zmieniających się sytuacji, ale nakładają dużą złożoność na podstawową implementację.
Wiele algorytmów decyzyjnych jest na tyle prostych, że można je wyrazić jako prosty program oparty na tabelach, bez złożoności wynikającej z prawdziwego silnika reguł.
źródło
Zdecydowanie polecam silniki reguł biznesowych, takie jak Drools, jako open source lub Commercial Rules Engine, takie jak LiveRules.
źródło
Naprawdę nie rozumiem niektórych punktów, takich jak:
a) ludzie biznesu muszą bardzo dobrze rozumieć biznes lub;
b) brak zgody co do ludzi biznesu nie musi znać reguły.
Dla mnie, jako osoby po prostu dotykającej BRE , korzyści płynące z BRE to tak zwane umożliwienie systemowi dostosowania się do zmian biznesowych, dlatego skupia się na adaptacji do zmian.
Czy ma znaczenie, czy reguła ustawiona w czasie x różni się od reguły skonfigurowanej w czasie y, ponieważ:
a) ludzie biznesu nie rozumieją biznesu lub;
b) biznesmeni nie rozumieją zasad?
źródło