[RBAC] Wat te doen met Business Rules?

[Verwijderd]

Ik ben momenteel bezig met het Role Base Access Control (RBAC) gedeelte van een MVC Framework. Het framework kent modules, en een module kent acties.
Wanneer een actie aangeroepen wordt, zal voordat de execute() methode aangeroepen wordt eerst gecontroleert moeten worden of de User bepaalde rechten heeft;

PHP:

class PageEditAction extends Action {

  function getCredentials() {
    $context = &$this->getContext();
    $user = &$this->getUser();
    return $user->getCredential('PageEdit');
  }

  function execute() {}
  function validate(&$validatorManager) {}
  function handleError() {}
  function getDefaultView() {}
  function getRequestMethod() {}
}

Allemaal leuk en aardig, en dit valt allemaal prima te behappen. Wat nou, als je een gebruiker in een bepaalde Role alleen zijn eigen pagina's wil laten bewerken. Je wil daarvoor niet twee Actions maken met elk een eigen execute() methode die nauwelijks verschilt. De vraag is; waar laat je de Business Rules (met betrekking tot toegang)? Stel er is een Role 'JuniorPurchaser' die goederen tot 10.000 euro per order mag inkopen. Ga je zulk soort gevallen allemaal hardcoded in programmeren? Wat nou als er meerdere Purchasers komen, als de bedragen veranderen etc? Hoe houd je de flexibiliteit, zonder een hele applicatie te moeten doorlopen bij aanpassingen. Hebben jullie hier mee te maken gehad? Wat zijn jullie bevindingen? Google bevragen met RBAC + Business Rules, levert geen bevredigende resultaten.

[mulder]

Dat hoort allemaal gewoon in de database, je kunt toch gewoon in execute checken of iemand rechten heeft op dat object? En in het 2e geval zou ik bv Purchaser een Propery MaxOrderAmount aanmaken die je uit een tabel met RoleID en MaxOrderAmount vist (mocht dat individueel instelbaar moeten zijn, anders check het via de Role)

[Verwijderd]

Als een algoritme niet veel verschild (in dit geval de execute methode van de twee action) dan kan je gebruik maken van de template design pattern. Alles wat anders implementeer je in de concrete klassen. maar is wel een beetje zinloos als alleen het bedrag verschilt (gedrag moet ander zijn). Gebruik liever hiervoor de database.

en wat betreft de toegang voor de gebruikers kan je inderdaad in de database opslaan.