Herbruikbare Parameteriseerbare Adapters

 
03 april 2008

Tijdens cursussen en seminars gaat het vaak over hoe koppelingen tussen het domein en de service tot stand komen. Meestal worden in deze context generieke parameteriseerbare adapters genoemd. Voor veel mensen blijft dit concept echter nog een beetje vaag. Hierom hebben we besloten het adapter framework wat we hiervoor gebruiken publiek beschikbaar te stellen.


Onderstaand de link naar het framework inclusief het mancala voorbeeld.

Sogyo Adapter Framework versie 1.0.2

Het voorbeeld geeft een duidelijk beeld hoe de verschillende adapters gebruikt kunnen worden om verschillende componenten op een losse manier aan elkaar te koppelen.
Het framework is voor iedereen vrij te gebruiken. Mocht je besluiten om het in een project te gebruiken, dan zou ik alleen willen vragen of je je ervaringen wil delen in de reacties op deze post of anders via de mail (rwolter@sogyo.nl). We zijn namelijk erg geïnteresseerd in het functioneren van het framework bij andere projecten.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Architectuur, Development, Java (EE)

Tags: , , ,


Reacties (8)

  • Danny Lagrouw schreef:

    Mijn eerste gedachte toen ik Ralf de bootstrapping in zijn framework zag presenteren was inderdaad ook: Spring! Maar dat kan ook zijn omdat dat op 20 maart was ;).
    Voor wat betreft bootstrapping doe ik wat concessies aan Ralf’s ideale situatie en kan ik het een stuk simpeler houden.

    Ralf, ik ben het zeker met je eens dat het aan- of afwezig zijn van zo’n superclass niet uit mag maken voor je domeinclasses. Harde koppelingen in zo’n superclass naar de buitenwereld zijn helemaal uit den boze. Maar dan nog hoef je het gebruik van bijvoorbeeld een persistentieframework als Hibernate niet uit te sluiten. Iets wat je framework op dit moment doet door blijkbaar nog teveel “aanwezig” te zijn in alle domeinclasses (al is het dan niet door een superclass).

    En inderdaad, ik denk ook dat aspects (bij gebrek aan metaprogrammeermogelijkheden in Java; Rubyisten krijgen vaak een blik van medelijden in de ogen als ik het over AOP heb) ingezet kunnen worden om het sturen van events vanuit je domeinclasses onzichtbaar te maken.

    Geplaatst op 09 april 2008 om 8:25 Permalink

  • Ralf Wolter schreef:

    Ik ben eerder geneigd te zeggen dat aspect oriented programming een open-class-achtige functionaliteit bied voor statische talen, dan dat open classes een aop-achtige functionaliteit bied aan dynamische talen. ;)

    Ik ben geen tegenstander van aop. Het is een handige manier om een onzichtbare koppeling te creeren. Het zal ook wel een rol in verdere uitwerkingen gaan spelen. Maar daar geld ook dat het passief moet blijven. Een object moet nog steeds buiten het framework kunnen functioneren.

    De lazy-loading functionaliteiten zijn een mooi voorbeeld. Het koppeld de objecten hard aan het framework. Hierdoor ontstaan vaak koppelingen die niet verwacht worden en vervolgens geen rekening meer gehouden wordt.

    Nu zie ik niet hoe lazy-loading zo snel op een andere manier opgelost kan worden. Het blijft een activiteit waarbij de data ergens anders vandaan moet komen. En de gewoven lazy object van de frameworks worden meestal alleen gewoven als het object ook daadwerkelijk lazy is waardoor onder normale omstandigheden met het oorspronkelijke object gewerkt wordt.

    Geplaatst op 08 april 2008 om 23:07 Permalink

  • Alef Arendsen schreef:

    Interessant, actieve en passieve superclasses :-).

    Ik zeg aspects to the rescue. Maar goed, nu wordt ik vast gekielhaald :-).

    De hele wereld gebruikt inmiddels proxies of bytecode-moficatie (in meer of minder opzichtige vorm) of andere aspect-achtige technieken om allerlei gedragingen aan objecten toe te voegen. Zo ongeveer *elke* Object-Relational Mapper doet het om lazy loading toe te passen (zonder extensie van een base object. Daarnaast kun je zelfs in SmallTalk en meer dynamische talen als Ruby aspect-achtige functionaliteit (mixins voornamelijk) vinden.

    groet,
    Alef

    Geplaatst op 08 april 2008 om 21:22 Permalink

  • Ralf Wolter schreef:

    @Danny

    Een superclass is naar mijn mening een verleidelijke koppeling. In een framework worden al snel bepaalde regels bedacht over hoe de classes eruit moeten zien. De volgende observatie is dat we in de meeste classes vrijwel identieke code hebben. Dat stap daarna om die code naar boven te trekken is snel gemaakt.

    Toch is het een keuze die beperkt. Je kunt immers maar een enkel framework gebruiken dat een superclass vereist. Daarnaast zijn de domein classes nu hard gebonden aan het framwork.

    Maar zoals in het voorbeeld te zien ik kies ik uit eindelijk ook voor een superclass. Alle objecten erven over van Observable. Belangrijk hierbij vind ik dat de superclass passief is. Observable belet het normaal gebruik buiten het framework niet er worden eventueel observer genotificeerd, maar in de default situtatie zijn er geen observers en gedraagd de superclass zich alsof hij niet aanwezig is.

    Sommige persistentie framework hadden hardere koppelingen in de superclass. Het gebruik van het object zonder de benodigde infrastructuur leverde veel fouten op. Dit kwam omdat de superclass de database probeerde aan te spreken.

    In het algemeen is dus mijn mening, geen superclass, maar als het echt moet een passieve superclass.

    Geplaatst op 08 april 2008 om 21:13 Permalink

  • Alef Arendsen schreef:

    Hey Ralf, voor dat bootstrapping, daar kun je toch mooi Spring voor gebruiken :-).

    Even zonder gein, ik heb maar eens gereageerd (zie blog.arendsen.net) op jouw versie van ‘I don’t digg Spring’ op mijn blog. Ben benieuwd naar je reacties!

    Geplaatst op 07 april 2008 om 20:36 Permalink

  • Danny Lagrouw schreef:

    Zo’n superclass is niet ideaal maar wel ontzettend handig. Ik ontkom er ook niet aan in mijn DDD-variant (geinspireerd door de geslaagde masterclass heb ik eindelijk mijn code maar eens opgeschoond en online gezet, zie http://code.google.com/p/bastionframework/ voor een event-based framework met JPA en Db4o ondersteuning). Maar ach, alle Java-objecten extenden toch ook van Object, dus waarom mogen domeinobjecten niet van DomainObject extenden?

    Geplaatst op 06 april 2008 om 20:10 Permalink

  • Ralf Wolter schreef:

    Geen gebruik maken van een superclass die deel uitmaakt van het framework was een bewuste keuze voor deze opzet. Het idee dat ik probeer te bereiken is dat zowel het domein als de services ontkoppeld zijn van elkaar en het framework.

    Ik ben erg benieuwd naar je oplossing voor het bootstrappen. Het is hier namelijk de enige code die afhankelijkheden heeft naar alle componenten, om dat op een eenvoudigere manier te kunnen definieren zou het plaatje compleet maken.

    Geplaatst op 03 april 2008 om 23:04 Permalink

  • Ivo Limmen schreef:

    Leuk dat je je code hebt gepubliceerd, ikzelf ben nu ook bezig met een DDD core library zodat ik niet alle code voor elk project opnieuw hoef te schijven. In mijn library heb ik echter niet alleen adapters zitten maar ook de basis class: DomainObject en PersistableDomainObject. Tevens heb ik een ‘standaard’ oplossing voor bootstrappen gebouwd. Ik ga hier binnenkort over bloggen.
    De manier hoe je gebruik maakt filters verschilt met die van mij: ik maak gebruik van adapters die kunnen filteren in plaats van een filter die je kan mee geven aan een adapter. Ik moet binnenkort maar even wat tijd vrijmaken om je code goed door te nemen…

    Geplaatst op 03 april 2008 om 21:16 Permalink