Új hozzászólás Aktív témák

• #9862 akrobet tag

  Új Válasz 2016-06-11 20:49:23 #9862

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  akrobet

  tag

  Sziasztok!

  Tanácsot szeretnék kérni egy üzleti szabálymotor (business rule engine) megtervezésével kapcsolatban.

  Angol leírás: [link] - szerintem sokkal érthetőbb annak aki tud angolul mint az én alábbi fordításom

  A szabálymotor egy rendelés feldolgozó rendszer része lenne, ehhez hasonló funkciókkal:

  - ha egy rendelés érkezik egy fizikai termékért, generáljon egy csomagolási szelvényt (packaging slip) a küldéshez

  - ha egy rendelésérkezik egy könyvért, hozzon létre egy másolatot a csomagolási szelvényről a jogdíj osztály részére

  - ha egy rendelés érkezik egy tagságért, aktiválja a tagságot

  - ha egy rendelés érkezik egy tagság előléptetéséért (upgrade) , érvényesítse az előléptetést (apply the upgrade)

  - ha egy rendelés érkezik a "Síelni tanulunk" nevű filmért, addjon hozzá egy "Elsősegély" nevű videót a csomagolási szelvényhez.

  ...

  A rendszernek ehhez hasonló szabályok százait kell hogy tudja feldolgozni, és a szabályok folyamatosan bővülnek és változnak a rendszer élettartama alatt.

  Tehát a feladat egy olyen rendszer megtervezése ami elég flexibilis hogy kezelni tudja a bonyolult szabályokat, úgy hogy minél kevesebb karbantartást igényeljen a rendszerfejlesztőtől.

  A feladatban előírják, hogy az egyszerűséget előnynek tekintik az rendszer architekturában. Tehát bonyolult design patternek használata nélkül, ha nincs létjogosultsága.

  A kódnak teszelhetőnek és könnyen olvashatónak kell lenni.

  Nah, ez lenne a feladat leírása (fordítása).

  Két megoldás között vacilálok, mivel a feladatban (gondolom direkt) nem utaltak rá, hogy pontosan milyen gyakran változnak ezek a szabályok és hogy a rendszer felhasználói (webshop tulaj) tudjanak-e maguk változtatni / hozzáadni új szabályokat.

  1. megoldás - lényegében hardcodeolni a szabályokat termék típus szerint
  előnyök: nem igényel bonyolult programozási "trükköket" mint reflection, expression trees, stb..
  hátrányok: minden szabályvátloztatás programozót igényel és egy új rendszer verzió beüzemelését (deploy)

  2. megoldás - a szabályok dinamikusan létrehozhatók a felhasználók által, pl definiálva a termék típusát (class name) és paramétereit (property) és a szabályokat adatbázisba menteni, és vizsgálásnál kiolvasni, majd reflectionnel megvizsgálni hogy az adott megrendelés, stb. megfelel-e a szabályoknak és aszerint végrehajtani az utasítást.

  előnyök: rugalmas rendszer, a szabályok létrehozása nem igényel programozót
  hátrányok: bonyolultabb implementáció, nem túl elegáns kód (reflectionnel), ha megváltozik egy utasítás neve a kódban, az adatbázisban tárolt szabályok nem működnek többé

  Én személy szerint a második megoldás felé hajlanék, mert szabályok százainak karbantartása szerintem túl költséges lenne. A problémám csak az hogy sokan írják a reflectionről pl. stackoverflow-n, hogy lassú és nem alkalmazható olyan helyeken ahol utasítások millióit kell végrehajtani.

  Valakinek esetleg lenne ötlete/tapasztalata ilyen rendszer fejlesztésével esetleg a két megoldás közül melyik lenne helytállóbb?

  Programozási nyelv: C#

  Bocsi a hosszú postért, de szerintem szükséges a feladat megérteséhez. Ha furcsa magyar megfogalmazást használok az azért van mert csak angolul tanultam programozást és nem tudom a magyar kifejezéseket.

Új hozzászólás Aktív témák