[Java] Historiek bijhouden van bepaalde acties/events

[-FoX-]

Ik werk momenteel aan een applicatie waar bepaalde acties / events onderschept dienen te worden, om zodoende weggeschreven te worden als historiek. Maar van bepaalde andere acties moeten berichten verstuurd worden naar de gebruiker via de applicatie (alerting/notification). Het zijn dus niet alle acties waarop gereageerd moet worden.

Vb: Als een klant een betaling doet, moet dit opgenomen worden in de klant's historiek.

Het zijn niet alle acties waar een historiek van bijgehouden dient te worden.

Ik heb zelf natuurlijk ook al aan diverse mogelijkheden gedacht zoals DB triggers (lastiger omdat het nog MySQL 4 is), AOP, handmatig dubbele inserts doen in een transactie, bepaald design pattern, ... ?

Wie kent er een goede oplossing voor dit probleem???

[TheNameless]

Misschien het Memento pattern gebruiken, in samen werking met het Command pattern en die laten serializeren?

Voor het filteren van events zal ook wel een pattern geschikt zijn (geen idee welke trouwens )

[ Voor 44% gewijzigd door TheNameless op 07-09-2006 12:27 ]

[kasper_vk]

MayaFreak schreef op donderdag 07 september 2006 @ 12:23:
[knip!]
Voor het filteren van events zal ook wel een pattern geschikt zijn (geen idee welke trouwens )

Ik gok het decorator pattern; dacht ik tenminste direct aan.
In 2e instantie denk ik aan het proxy pattern; anyway, je maakt een extra laagje boven je daadwerkelijk event-handling, welke voor de interessante events de extra actie doet (logging e.d.); dat laagje (een class dus) krijgt dezelfde interface als de eventhandler zelf.

Het decorator of proxy object kijkt dan of er nog gave extra acties uitgevoerd moeten worden, afhankelijk van de meegegeven parameters (Actions?).

[ Voor 38% gewijzigd door kasper_vk op 07-09-2006 13:23 ]

[Cuball]

Ik zou voor de AOP oplossing gaan, lijkt perfect hiervoor

[-FoX-]

Cuball schreef op donderdag 07 september 2006 @ 15:01:
Ik zou voor de AOP oplossing gaan, lijkt perfect hiervoor

Wat een prachtige onderbouwing hiervoor . Nee, iets meer onderbouwing lijkt me wel gewenst in dit geval. Ik heb ook al erg aan AOP zitten denken, maar ben wel nog redelijk noobisch hierin..

Waarom AOP verkiezen boven command/memento, database triggers, manuele aanpak?
Ik zie zelf eigenlijk het nut niet zo van een command/memento pattern hier; een command is slechts een groepering van logica in een commando. Ok, ik kan dit als een transactie beschouwen, maar wat is verder de toegevoegde waarde van deze aanpak?

[Kwistnix]

Wat is precies het cross-cutting concern dat je met AOP zou willen oplossen dan
Je hebt verschillende acties/events binnen je applicatie en van slechts sommige van die acties/events moeten per user apart in een historisch overzicht vastgelegd worden in een op zich zelf staande tabel/tabellen in de database. Het probleem is dus dat je historisch-belangrijke events van niet-historisch-belangrijke events moet scheiden en dat je voor de historisch-belangrijke events dus een extra database query zou moeten uitvoeren? Op welke manier biedt AOP daar dan uitkomst?
Het historisch overzicht maakt toch gewoon deel uit van dezelfde BL of zie je het meer als een vorm van logging?

[ Voor 9% gewijzigd door Kwistnix op 07-09-2006 16:52 ]

[-FoX-]

Ik denk ook niet dat AOP de meest ideale oplossing is. Een facade aanbieden voor de gebundelde operaties is ook nog een mogelijkheid, maar ik weet eigenlijk niet goed welke aanpak ik nu het best kan verkiezen boven een ander?

[makreel]

http://java.sun.com/bluep...s/InterceptingFilter.html

is ook voor logging.

Is deze die MayaFreak bedoelde?

[ Voor 16% gewijzigd door makreel op 08-09-2006 12:43 ]

[-FoX-]

makreel schreef op vrijdag 08 september 2006 @ 12:41:
http://java.sun.com/bluep...s/InterceptingFilter.html

is ook voor logging.

Is deze die MayaFreak bedoelde?

Wat heb ik aan een intercepting filter? Niks lijkt me..

[makreel]

Omdat je het woord "onderschept" gebruikte, vandaar dat ik er op kwam.

[The - DDD]

Op zich is een filter chain nog zo gek nog niet.

Echter ipv. zaken weg filteren monitor je op bepaalde event types. Wanneer een type langs komt, dan doe je een actie in het filter (vastlegging in de database) en laat je vervolgens de executie doorgaan.

Het pattern daarvoor heet echter Chain of Command of Chain of Responsibility.

[ Voor 13% gewijzigd door The - DDD op 08-09-2006 13:52 ]

[bloody]

The - DDD schreef op vrijdag 08 september 2006 @ 13:50:
Op zich is een filter chain nog zo gek nog niet.

Echter ipv. zaken weg filteren monitor je op bepaalde event types. Wanneer een type langs komt, dan doe je een actie in het filter (vastlegging in de database) en laat je vervolgens de executie doorgaan.

Het pattern daarvoor heet echter Chain of Command of Chain of Responsibility.

Ja, dit is de standaard GoF manier (elke schakel forward naar een volgende).
Wellicht kun je overwegen om de schakels de schakels te laten, en de logica (lees:verantwoordelijkheid) voor het forwarden in je chaincontroller te leggen.
Zo heb je meer garantie (minder code --> minder risico) dat een kapotte schakel niet de hele chain stuk maakt.