Observer in combinatie met een facade

[D-Raven]

Ik ben momenteel bezig met een database applicatie.
De applicatie is opgesplitst in 2 delen. De backend en de frontend.
De backend bevat in princiepe alle implementatie om gegevens op te halen en te muteren.
De frontend bevat de gui. (duh)

Omdat wij een lage koppeling tussen de frontend en backend willen creeren implementeerd de backend een Maincontroller welke volgens het facade patroon een interface aanbied naar de frontend.

De bedoeling is dat de GUI de interface van de facade gebruikt om te communiceren met de backend. Alleen in de gui worden ook lijsten van gegevens weergegeven. Indien men een record in een van deze lijsten wijzigd, door middel van een toevoeging of andere mutatie. Dan willen we dat deze lijst in de gui geupdate wordt (ofcourse ). Omdat we niet bij iedere insert/update/delete call naar de facade gelijk daarna een update statement neer willen zetten die de desbetreffende lijst update, ben ik van plan om het observer patroon te implementeren.

Alleen nu zit ik dus met het volgende probleem.

Als je vanuit de gui een subscribe doet op je subject dan wil je dat deze subject zo specifiek mogelijk is. Ik wil me dus kunnen subscriben op alle mutaties m.b.t Users, en niet dat ik gedwongen ben om me te subscriben op ALLE mutaties over het gehele programma.

Om dit te implementeren heb je in dit geval 2 mogelijkheden (zover ik het zie).

1: Je maakt in de facade een onderverdeling in functionaliteit en bied voor iedere set van functionaliteiten een subject implementatie aan. (M.a.w de facade krijgt voor iedere set van functionaliteiten een subscribe/unsubscribe/notify functie (opmerking: verwachting is dat we dan een stuk of 10 sets krijgen).

2: Je maakt in de gui een laag aan waarin controllers zitten die een subset van de interface van de facade implementeren. In die controllers kun je dan het observer patroon implementeren.
De gui praat tegen deze specifieke controllers om gegevens op te halen.

Ik ben dus in discussie met een collega over welke oplossing we zouden moeten nemen.
Ikzelf ben voor oplossing 2. Omdat je dan een betere opdeling van verantwoordelijkheden hebt plus je krijgt niet in de facade tig implementaties van je Subject interface.
Nadeel is dat je ogenschijnlijk een hogere koppeling hebt met je backend. Mijn collega ziet het voordeel niet echt.

Mijn collega is voor oplossing 1. Onder het motto dat je een lagere koppeling hebt tussen je frontend en backend. Plus hij vindt oplossing 2 veel omslachtiger en ziet niet in waarom je het observer patroon niet in de facade kan implementeren (hetzij op de manier zoals eerder beschreven of op een andere manier).

ik vindt oplossing 2 veel netter en je hebt een betere verdeling van verantwoordelijkheden. Maar, inderdaad, als je naar het klassediagram gaat kijken dan ziet het er wel omslachtig uit. Want in feite maak je een kopie van de controllers uit de backend, in de frontend
Het ziet er dan ongeveer zo uit (textuele weergave )

code:

[backend]

[laag specifieke controllers]

[facade welke de gecombineerde interfaces van de specifieke controllers aanbied]

[einde backend]

[frontend]

[laag specifieke controllers welke met de facade praten en observer patroon implementeren]

[gui welke met de specifieke controllers praten]

[einde frontend]

Misschien zien jullie wel een hele andere oplossing en zit ik en mijn collega momenteel gewoon vast in een bepaalde gedachtengang. Of indien dit niet het geval is, voor welke oplossing zouden jullie kiezen en waarom?

Mijn collega en ik zitten momenteel in een soort van stalemate Vandaar dit topic, we hopen tot nieuwe inzichten te komen of om genoeg argumenten te hebben om de ander, spreekwoordelijk te begraven

[Alarmnummer]

D-Raven schreef op dinsdag 08 augustus 2006 @ 12:26:
Ik ben momenteel bezig met een database applicatie.
De applicatie is opgesplitst in 2 delen. De backend en de frontend.

Ik neem aan dat bij de backend ook de business logic zit?

Omdat wij een lage koppeling tussen de frontend en backend willen creeren implementeerd de backend een Maincontroller welke volgens het facade patroon een interface aanbied naar de frontend.

Alhoewel ik die maincontroller niet kan plaatsen, klinkt het verhaal ok (tot zover).

De bedoeling is dat de GUI de interface van de facade gebruikt om te communiceren met de backend. Alleen in de gui worden ook lijsten van gegevens weergegeven. Indien men een record in een van deze lijsten wijzigd, door middel van een toevoeging of andere mutatie. Dan willen we dat deze lijst in de gui geupdate wordt (ofcourse ).

....dejavu.....

Omdat we niet bij iedere insert/update/delete call naar de facade gelijk daarna een update statement neer willen zetten die de desbetreffende lijst update, ben ik van plan om het observer patroon te implementeren.

Ojee..

[java] MVC kan veel generieker

Damn.. wat een crap AOP was een veel minder intrusive oplossing.

Misschien zien jullie wel een hele andere oplossing en zit ik en mijn collega momenteel gewoon vast in een bepaalde gedachtengang. Of indien dit niet het geval is, voor welke oplossing zouden jullie kiezen en waarom?

Gewoon je screen opnieuw gaan renderen als dat mogelijk is. Bespaard je al dit gezeik.

[D-Raven]

Alarmnummer schreef op dinsdag 08 augustus 2006 @ 22:25:

Ik neem aan dat bij de backend ook de business logic zit?

yup

Ojee..

[java] MVC kan veel generieker

Damn.. wat een crap AOP was een veel minder intrusive oplossing.

Het is in Winforms c#.
Interesant topic, ik heb eens doorheen gelezen, Correct me if im wrong, maar zover ik zie werkt dit het beste als je een persistente BLL hebt. Iets wat ik hier dus niet heb
Maar inderdaad AOP zou een uitkomst kunnen zijn, ik weet alleen niet of dit mogelijk is in c#

Gewoon je screen opnieuw gaan renderen als dat mogelijk is. Bespaard je al dit gezeik.

Opnieuw renderen als dit mogelijk is. Hoe moet ik me dat voorstellen? Als ik daarmee wil afdwingen dat hij zijn data op het form gaat verversen dan zal ik met de paint methode aan de slag moeten. Wat ik dus niet wil in deze context.

Ik heb ook al naar IOC (Inversion Of Control) zitten kijken. Heel interesant, alleen waarschijnlijk zal dan het hele ontwerp op zn kop moeten.

[ Voor 8% gewijzigd door D-Raven op 09-08-2006 09:12 ]

[kenneth]

http://www.castleproject.org/index.php/AspectSharp

Geen flauw idee of het wat is hoor

[D-Raven]

Laat ik daar nou net tegenaanlopen

[Alarmnummer]

D-Raven schreef op woensdag 09 augustus 2006 @ 09:05:
Het is in Winforms c#.
Interesant topic, ik heb eens doorheen gelezen, Correct me if im wrong, maar zover ik zie werkt dit het beste als je een persistente BLL hebt. Iets wat ik hier dus niet heb

Hetgeen jij in je geheugen hebt, daar wil je naar kunnen luisteren. Het feit dat het ook in de db opgeslagen kan worden maakt imho niet veel uit.

Opnieuw renderen als dit mogelijk is. Hoe moet ik me dat voorstellen? Als ik daarmee wil afdwingen dat hij zijn data op het form gaat verversen dan zal ik met de paint methode aan de slag moeten. Wat ik dus niet wil in deze context.

Niet painten, maar het scherm gewoon updaten. Meestal weet je wel welke velden je moet updaten, dus dat zou je dan met de hand kunnen doen. En anders update je gewoon alle velden (ook al zitten er onnodige verversingen tussen). Dan hoef je je model niet zo te gaan verzieken.

Verder heb ik ook geen enkel idee van het type applicatie dat je wilt gaan maken. Dus tja.. oplossing is lastig.

[D-Raven]

Het is een applicatie voor het managen van gegevens in een bestaande database.

Gewoonweg alle velden, of specifieke velden updaten bij iedere call in de gui gaat niet. Er zijn namelijk nogal wat constraints tussen gegevens. Het datamodel is vrij ruk. Slechte of geen constraints tussen afhankelijke gegevens en dergelijke. Dus deze moeten allemaal in de applicatie afgedwongen worden.
Dit gebeurd voornamelijk in backend. Maar het resultaat is dus dat als je bv een gebruiker verwijderd, alle entry's in koppeltabellen voor die user ook verwijderd worden.
Koppeltabellen waarvan vaak de inhoud weer in de gui op een of andere manier wordt weergegeven.

Indien je dit handmatig wilt doen dan zul je dus in je gui overal waar een mutatie wordt uitgevoerd handmatig een call naar de gui moeten gooien om zichzelf te updaten. Dit creeert een hoop extra code. Welke foutgevoelig is, onderhoudtechnisch een ramp, en in het algemeen de rillingen over mn lijf laten lopen .
Stel dat er iets veranderd waardoor je die update calls moet aanpassen. Ga dan maar eens zoeken naar waar je dat ook allemaal weer deed. Wil je het een beetje efficient doen dan zullen die calls waarschijnlijk ook nog context gevoelig zijn. (in andere woorden ze laten de gui alleen delen updaten die nodig zijn, en niet alles, vanwege performance enzow).

Vandaar dat ik een observer patroon wil implementeren. Een component in de frontend subscribed op een bepaald type gegevens in de backend en krijgt een notify als deze set gewijzigd zijn. Waarna deze de gui update.

Omdat de backend en frontend zoveel mogelijk gescheiden moeten kunnen worden, en wij nou niet 2 dagen niks kunnen doen , hebben we voor oplossing 2 gekozen en zit het momenteel zo in elkaar.
De backend bied een aantal "interfaces" aan. De frontend heeft een laag welke tegen deze interfaces aan praat.
Vanuit de gedachtengang dat gui dingen in de frontend moeten blijven en de backend alleen verantwoordelijk is voor het aanleveren van data en het afdwingen van intengriteit mag de backend niks weten van een observer implementatie.
Vandaar de extra laag in de frontend. In feite is dit niks meer dan een kale kopie van de interfaces die de backend aanbied. Enigste verschil is dat deze laag observable is. (niet de gehele laag als 1 geheel, maar elke interface apart natuurlijk).

Op deze manier heb je toch die scheiding en kun je vanuit je gui muteren wat je wilt zonder verder rekening hoeven te houden met het updaten van gegevens aangezien dit automatisch gebeurd. Natuurlijk moet je wel zorgen dat je je als gui zijnde heb ingeschreven bij de desbetreffende subject waarvan je op de hoogte wilt gehouden. Maar dit is een eenmalige actie.