[DDD|Spring] general discussion

[Alarmnummer]

Met dit topic wil ik een discussie starten over DDD binnen Spring. Binnen Spring 1 was het erg lastig om met een rijk domain model te werken aangezien je erg slecht aan dependencies kunt komen bij objecten die niet door de app context zijn aangemaakt. Maar vanaf Spring 2 is dit wel mogelijk en daardoor kunnen we dus een rijk domain model maken ipv een Anemic Domain Model.

Ik ben de laatste tijd veel bezig met het onderwerp: ik probeer te kijken welke technische issues we allemaal voor de kiezen gaan krijgen. Welke mogelijke oplossingen bruikbaar zijn (binnen een bepaalde context) en welke oplossingen eventueel helemaal niet bruikbaar zijn. Hoe we eventueel onze hele aanpak moeten aanpassen. Wat de gevolgen zijn voor componenten (krijgen we misschien security issues? caching issues? etc etc etc).

Mijn vraag is dus hoe jullie domain driven design binnen Spring zien. Welke vragen hebben jullie? Welke oplossingen hebben jullie? Moeten jullie overtuigd worden van het voordeel van DDD? Of kunnen jullie mij overtuigen dat DDD helemaal niet handig is Dus alles mbt DDD en Spring kan je in dit topic kwijt.

[ Voor 8% gewijzigd door Alarmnummer op 19-06-2006 10:44 ]

[Cuball]

Ik ben nog maar halfweg evans boek dus voorlopig heb ik niet zo veel op te merken, ik zal het topic wel volgen :-)

Als Evans spreekt van een Repository zie jij dat dan als een DAO binnenin je domein object ? (wat nu mogelijk is via Spring2)

[Alarmnummer]

Cuball schreef op maandag 19 juni 2006 @ 11:25:
Als Evans spreekt van een Repository zie jij dat dan als een DAO binnenin je domein object ? (wat nu mogelijk is via Spring2)

Volgens mij is dat gewoon een DAO (ik zie niet in (op dit moment) om daar nog eens een structuur voor aan te gaan maken). Dus totdat ik het verschil weet tussen een DAO en een Repository, denk ik dat ze hetzelfde zijn.

[ Voor 18% gewijzigd door Alarmnummer op 19-06-2006 11:37 ]

[-FoX-]

Ik zie DDD eigenlijk als een betere aansluiting op de development methodologie en gelijkertijd een betere weerspiegeling van het probleem domain. Echter vraag ik me wel af in welke mate dit toepasbaar is in een real-world omgeving en tot waar je moet gaan.

Encapsulation is een van deze zaken. Je domain model mag geen getters/setters bevatten die de state van het object kunnen wijzigen; dus je domain objects zouden immutable moeten zijn (zoals java.util.String). In hoeverre is dit werkbaar? Ga je dan niet gewoon terug zitten werken met DTOs?

[Alarmnummer]

-FoX- schreef op maandag 19 juni 2006 @ 12:48:
Ik zie DDD eigenlijk als een betere aansluiting op de development methodologie en gelijkertijd een betere weerspiegeling van het probleem domain. Echter vraag ik me wel af in welke mate dit toepasbaar is in een real-world omgeving en tot waar je moet gaan.

Encapsulation is een van deze zaken. Je domain model mag geen getters/setters bevatten die de state van het object kunnen wijzigen; dus je domain objects zouden immutable moeten zijn (zoals java.util.String).

1) Getters is geen probleem
2) Setters zijn wel een probleem. Meestal is het handiger om via een state change methode iets te doen. Stel dat ik een employee heb met een salaris en met een ontslag datum en expose die via setters.

code:

class Employee{

    int salaris;
    Date ontslagDatum;

    void setSalaris(int salaris){
         this.salaris = salaris;
    }

    void setOntslagDatum(Date ontslagDatum){
       this.ontslagDatum = ontslagDatum;
   }
}

Dan kan het voorkomen dat ik een employee heb met een salaris > 0, maar die wel ontslagen is. Als je via een state change methode werkt, bv fire, dan kan je dit in een keer doen:

code:

class Employee{

    int salaris;
    Date ontslagDatum;

    void fire(){
        ontslagDatum = new Date();
        salaris = 0;
    }
}

Dus mbv dit soort methodes kan je veel beter je class invarianten afdwingen.

[ Voor 15% gewijzigd door Alarmnummer op 19-06-2006 13:21 ]

[-FoX-]

Klopt, ook voor persistence is dit niet bepaald een issue (field accessors) alhoewel de authors van Hibernate in Action dit bijvoorbeeld wel sterk afraden en het ook niet default is.

Op welke manier ga je nieuwe objecten creeëren, full blown constructors?

Op het eerste zicht lijkt DDD mij geen pragmatische aanpak te kunnen bieden en misschien wel onnodige complexiteit creeëren. Ik ben dan ook erg benieuwd naar de sample app die momenteel ontwikkeld wordt om Rich Domain Models in de praktijk aan te tonen (Tennis game registratie systeem - door I21).

Nog een vraag die in me opkomt:
- Op welke manier maakt Spring 2.0 dit wel mogelijk?

[Alarmnummer]

-FoX- schreef op maandag 19 juni 2006 @ 13:29:
Klopt, ook voor persistence is dit niet bepaald een issue (field accessors) alhoewel de authors van Hibernate in Action dit bijvoorbeeld wel sterk afraden en het ook niet default is.

Op welke manier ga je nieuwe objecten creeëren, full blown constructors?

Via Hibernate mag je ook private setters aanroepen. Dus het kan ook op deze manier opgelost worden.

En tja.. full blown constructor... wel de enige echt handige manier om je objecten altijd in een goeie state te krijgen. Ik ben nog steeds tegen de setters die je veel met Spring ziet en ik weet uit ervaring dat vooral 'complexe' code dat je niet zelf hebt geschreven nagenoeg niet te onderhouden is: je weet niet meer wat gezet is en gezet mag worden.

Op het eerste zicht lijkt DDD mij geen pragmatische aanpak te kunnen bieden en misschien wel onnodige complexiteit creeëren. Ik ben dan ook erg benieuwd naar de sample app die momenteel ontwikkeld wordt om Rich Domain Models in de praktijk aan te tonen (Tennis game registratie systeem - door I21).

Hmmm. Ik weet niet hoe handig die game is voor dit gesprek (alles is namelijk in memory en geloof dat het ook niet echt bedoelt is om als voorbeeld te dienen voor webapplicaties).

Nog een vraag die in me opkomt:
- Op welke manier maakt Spring 2.0 dit wel mogelijk?

Het probleem aan Spring 1 is dat je geen dependencies in objecten die niet gecreeerd zijn door de applicatie context, kunt injecteren. Dus stel dat de employee een GoudenHandrukPolicy nodig heeft om de gouenhandruk te bepalen, dan heb je dus een issue om aan die referentie te komen.

Bij Spring 2 kunnen die referenties er dus wel in geinjecteerd worden. Dus je kunt nu ineens slimmere objecten maken omdat je belangrijke dependencies er nu in kunt injecteren.

[ Voor 5% gewijzigd door Alarmnummer op 19-06-2006 13:35 ]

[Cuball]

misschien beetje offtopic:

ik vroeg me nu af:
Stel je hebt een goed domein model opgemaakt, met alle business rules in je domein objecten volledig volgens de principes van DDD.

Ik weet niet juist hoe java ermee omgaat, maar wat met het geheugen gebruik ? Stel ik heb een entity met 100 tal business methodes, allemaal redelijk veel lijnen code, een heel pak instance variabeles... Verder heb ik een query die een 1000-tal van deze opbjecten ophaald. Wordt al deze code dan gedupliceerd in deze objecten die ik terug krijg? Met gevolg dat je geheugen volpropt met objecten die heel veel gedupliceerde methodes bevatten? (Of maakt java hier optimalisaties? Ben niet erg vertrouwd met de interne werking ervan)

Als ik al die business methodes in een service-laag plaats (singleton ofzo) dan wordt al deze code niet dupliceerd. Ik maak dan wel gebruik van een anemic domein model.

[Alarmnummer]

Cuball schreef op woensdag 21 juni 2006 @ 12:13:
misschien beetje offtopic:

ik vroeg me nu af:
Stel je hebt een goed domein model opgemaakt, met alle business rules in je domein objecten volledig volgens de principes van DDD.

Ik weet niet juist hoe java ermee omgaat, maar wat met het geheugen gebruik ? Stel ik heb een entity met 100 tal business methodes, allemaal redelijk veel lijnen code, een heel pak instance variabeles... Verder heb ik een query die een 1000-tal van deze opbjecten ophaald. Wordt al deze code dan gedupliceerd in deze objecten die ik terug krijg? Met gevolg dat je geheugen volpropt met objecten die heel veel gedupliceerde methodes bevatten? (Of maakt java hier optimalisaties? Ben niet erg vertrouwd met de interne werking ervan)

Daar hoef je niet bang voor te zijn. Java deelt de bytecode tussen alle threads (die dezelfde classloader gebruiken). Je betaalt dus eenmalig de prijs van code en daarnaast de prijs per instance...

Dus als code 2000 bytes.
Instance is 100 bytes en je hebt 10 instances
dan betaal je dus 2000+10*100=3000 bytes in totaal.

[ Voor 12% gewijzigd door Alarmnummer op 21-06-2006 21:33 ]

[Verwijderd]

Cuball schreef op woensdag 21 juni 2006 @ 12:13:
[..]

Stel je hebt een goed domein model opgemaakt, [..] Stel ik heb een entity met 100 tal business methodes, allemaal redelijk veel lijnen code, een heel pak instance variabeles...

Een object met honderd of meer methods en evenzoveel properties is over het algemeen een teken dat je domein model juist niet zo goed is

[Cuball]

Verwijderd schreef op donderdag 22 juni 2006 @ 00:32:
[...]


Een object met honderd of meer methods en evenzoveel properties is over het algemeen een teken dat je domein model juist niet zo goed is

akkoord, neem dan 10 methodes en 10000 objecten

[Cuball]

Als ik nu een entity wil zoeken, wijzigen en bewaren in een rijk domein model? Hoe zou dit scenario er dan uitzien?

De zoek methode om deze entity te vinden plaats je die dan in de Facade? Dus daar heb je ook ook toegang nodig naar je datalaag (net zoals voor DDD).

Als ik dan eenmaal het entity gevonden heb (deze kan enkel z'n staat wijzigen via gecontroleerde methodes, dus geen setters) en ik wil deze nu wijzigen in men presentatie laag?

Hier moet ik dus van men Domein object de gegevens gaan overpompen in een DTO om deze dan aan de client te tonen. Eenmaal de client de nodige wijzigingen heeft aangemaakt, en deze nu wil bewaren.
Nu moet ik de gegevens van de client terug in men domein object copieren? Maar hoe? Aangezien deze domein objecten geen setters hebben? Maak ik dan een nieuw object en via de constructor alle waarden die zich in het DTO object bevonden overnemen inclusief unieke ID van het object ?

Het effectief bewaren, in men Facade heb ik dan een bewaar functie (transacties), deze zou als het goed gebrijp in feite enkel een entity.save() moeten aanroepen waarin de nodige controles gebeuren ed. en het enity gepersist wordt in de databank.

Maar zoals het nu is maak ik dus een nieuw domein object aan om de gegevens vanuit men presentatie in men domein object te krijgen, of zou je gewoon het volledig domein object meegeven aan de presentatie?

Of hoe ziet volgens jullie dergelijk scenario eruit ?

[Alarmnummer]

Check deze blog ff:
DDD: Can I drop my service layer?

Ik zal straks nog even antwoord proberen te geven op je andere vragen.

[ Voor 29% gewijzigd door Alarmnummer op 22-06-2006 10:53 ]

[Alarmnummer]

Cuball schreef op donderdag 22 juni 2006 @ 10:45:
Als ik nu een entity wil zoeken, wijzigen en bewaren in een rijk domein model? Hoe zou dit scenario er dan uitzien?

Je wilt niet dat na iedere change je ook nog eens een update naar de db moet doen. Het mooiste zou zijn als ieder element dat wordt aangepast, automatisch in een 'unit of work' terecht komt. Bij moderne or-mappers zoals Hibernate en Toplink gebeurt dit automatisch als je een object registreerd bij de sessie (unit of work) of wordt opgehaald uit de db (dan komt het ook automatisch in de sessie terecht).

Ik denk dat het daarom ook erg belangrijk is welke 'ondergrondse' functionaliteit je van je or mapper aangeboden krijgt. Bij JDBC of Ibatis krijg je deze functionaliteit namelijk niet en hierdoor is er een groot verschil tussen 'hogere' or mappers zoals Hibernate/Toplink en lagere types zoals IBatis.

De zoek methode om deze entity te vinden plaats je die dan in de Facade? Dus daar heb je ook ook toegang nodig naar je datalaag (net zoals voor DDD).

Om entities te vinden kan je gewoon kletsen met je DAO's (Repositories) imho. DAO's staan op het zelfde niveau als je andere domain objecten (domain services, entities, value objects) en mag je gewoon raadplegen.

Als ik dan eenmaal het entity gevonden heb (deze kan enkel z'n staat wijzigen via gecontroleerde methodes, dus geen setters) en ik wil deze nu wijzigen in men presentatie laag?

Check hiervoor die link ff in mijn vorige post. Een service laag (die erg use case georienteerd is) is nog steeds erg waardevol. Dus direct domain objecten wijzigen is imho not done.

Het effectief bewaren, in men Facade heb ik dan een bewaar functie (transacties), deze zou als het goed gebrijp in feite enkel een entity.save() moeten aanroepen waarin de nodige controles gebeuren ed. en het enity gepersist wordt in de databank.

Op mjn blog staat een post: Business layer: why save/update(entity) is bad

Maar zoals het nu is maak ik dus een nieuw domein object aan om de gegevens vanuit men presentatie in men domein object te krijgen, of zou je gewoon het volledig domein object meegeven aan de presentatie?

Check de vorige post. Ik vind het niet zo'n probleem om do's aan de presentation laag door te geven. Uiteraard kan iemand allerlei methodes aanroepen, maar dat moet gewoon niet gedaan worden. DTO's creeeren is ook een optie, maar wel een pens vol werk.. Zo nu en dan moet je ook pragmatisch zijn en in dit geval vind ik het niet zo'n probleem.

[ Voor 13% gewijzigd door Alarmnummer op 23-06-2006 12:31 ]

[Scare360]

Alarmnummer schreef op maandag 19 juni 2006 @ 10:43:
Maar vanaf Spring 2 is dit wel mogelijk en daardoor kunnen we dus een rijk domain model maken ipv een Anemic Domain Model.

Misschien is het een idee om een voorbeeld te geven waar Spring 2 het verschil maakt?

[Scare360]

Alarmnummer schreef op maandag 19 juni 2006 @ 11:29:
Volgens mij is dat gewoon een DAO (ik zie niet in (op dit moment) om daar nog eens een structuur voor aan te gaan maken). Dus totdat ik het verschil weet tussen een DAO en een Repository, denk ik dat ze hetzelfde zijn.

Een repository is een collectie (achtige interface) van domain objecten. Zo wek je de illusie van een in-memory collectie van objecten en encapsuleer je de daadwerkelijke opslag en query technologie (bv door gebruik van Query Object pattern). Het is een best practice om voor iedere (root) aggregate in je domain model een repository te onderkennen.

Een DAO encapsuleert de technology gebruikt voor persistentie (bv T-SQL/ADO.NET). Vervolgens onderken je per domain object een DAO (althans in mijn ervaring).

In de praktijk zal je echter merken dat je de repository delegeert naar de dao's, dus terecht dat je stelt dat deze hetzelfde zijn. Ze lijken hetzelfde maar zijn conceptueel anders... naar mijn idee een implementatie detail.

Zie Keeping the Domain Model free from Persistence Logic. Je zal zien dat deze post iets meer implementatie detail bevat van datgene wat Jimmy beschrijft in zijn boek, waarbij hij spreekt over fake en infrastructuur repositories. Alternatief hiervoor is NWorkspace en in de toekomst misschien wel Spring.Data voor .NET.

Zie ook DAOVersusRepository

[ Voor 5% gewijzigd door Scare360 op 25-06-2006 10:17 ]

[Alarmnummer]

paulgielens schreef op zondag 25 juni 2006 @ 09:42:
[...]
Misschien is het een idee om een voorbeeld te geven waar Spring 2 het verschil maakt?

Dat heeft te maken met dependency injection in domain objects. Domain objecten worden vaak aangemaakt door een OR-mapper en het is dan niet mogelijk om een dependency erin te injecteren, vb:

code:

class Directeur implements Employee{
    private GoudenHanddrukPolicy goudenHanddrukPolicy;

    float goudenHandruk(){
          return goudenHanddrukPolicy,bepaalBedrag();
    }
}

Stel dat er een Directeur wordt aangemaakt door een OR-mapper, dan weet deze niet waar een instantie van de GoudenHanddrukPolicy vandaan gehaald moet worden. Als je de goudenHandruk methode aanroept krijg je dus ook een nullpointer exception.

In Spring 2 kan deze dependency alsnog geinjecteerd worden mbv AOP: op het moment dat de instantie is aangemaakt, krijg je (mbv een aspect) kans om nog extra werk te verzetten: het injecteren van de dependency. In de applicatie context kan je een 'template' bean aanmaken (waar dus een goudenhanddrukpolicy is gezet) en op basis hiervan kan de instantie dus gevuld worden met de juiste dependencies.

Dus ideaal voor dao's, strategies/policies en domain services.

[Alarmnummer]

paulgielens schreef op zondag 25 juni 2006 @ 10:13:
[...]
Een repository is een collectie (achtige interface) van domain objecten. Zo wek je de illusie van een in-memory collectie van objecten en encapsuleer je de daadwerkelijke opslag en query technologie (bv door gebruik van Query Object pattern).

Zo zie ik DAO's ook en verder hide je toch alle implementatie specifieke meuk in een implementatie en zie je van buitenaf alleen de interface. Ik zie dus nog steeds geen reden om aparte repositories te introduceren. Wellicht dat we ook een andere definitie er op na houden.

Het is een best practice om voor iedere (root) aggregate in je domain model een repository te onderkennen.

Mee eens (dao dus )

Een DAO encapsuleert de technology gebruikt voor persistentie (bv T-SQL/ADO.NET). Vervolgens onderken je per domain object een DAO (althans in mijn ervaring).

DAO per aggregate. OR mappers trekken alle dependencies automatisch toch wel mee. Dus een OrderDAO maar geen OrderLineDAO aangezien je toch nooit alleen een OrderLine zult willen aanspreken.

In de praktijk zal je echter merken dat je de repository delegeert naar de dao's, dus terecht dat je stelt dat deze hetzelfde zijn. Ze lijken hetzelfde maar zijn conceptueel anders... naar mijn idee een implementatie detail.

Ik zie het verschil niet.

Zie Keeping the Domain Model free from Persistence Logic. Je zal zien dat deze post iets meer implementatie detail bevat van datgene wat Jimmy beschrijft in zijn boek, waarbij hij spreekt over fake en infrastructuur repositories. Alternatief hiervoor is NWorkspace en in de toekomst misschien wel Spring.Data voor .NET.

Ik zal het eens bekijken.

DAOVersusRepository

[/quote]
Ik zal deze ook eens bekijken.

[Verwijderd]

In hoeverre geldt het anemic domain verhaal ook voor Spring .NET? Vandaag ben ik enthousiast begonnen in het Pro Spring boek en ben behoorlijk onder de indruk; het ziet er allemaal fantastisch uit. Maar werkt DI niet als je je objecten met reflection samenstelt? Of komt het doordat een O/R-mapper als bijv. NHibernate buiten de container context valt?

[Alarmnummer]

Verwijderd schreef op zondag 25 juni 2006 @ 15:56:
In hoeverre geldt het anemic domain verhaal ook voor Spring .NET?

Ik gok dat .NET daar ook last van heeft.

Spring.NET loopt voor zover ik weet erg achter de Java versie aan en zoiets als AspectJ bestaat niet voor .NET voor zover ik weet.

Of komt het doordat een O/R-mapper als bijv. NHibernate buiten de container context valt?

Precies. Daardoor krijg Spring 1.x de kans niet om de dependencies erin te injecteren. Bij Spring 2 kan dit door AspectJ wel.

[Verwijderd]

Alarmnummer schreef op zondag 25 juni 2006 @ 16:20:
[...]

Ik gok dat .NET daar ook last van heeft.

Spring.NET loopt voor zover ik weet erg achter de Java versie aan en zoiets als AspectJ bestaat niet voor .NET voor zover ik weet.

Volgens mij heb je daarvan ook een .NET tegenhanger, namelijk AspectSharp, dus dat zou het probleem niet mogen zijn.

[...]

Precies. Daardoor krijg Spring 1.x de kans niet om de dependencies erin te injecteren. Bij Spring 2 kan dit door AspectJ wel.

Ik kwam net wel het volgende tegen in de Spring .NET documentatie voor de meest recente point release:

void ConfigureObject(object target): Injects dependencies into the supplied target instance. The name of the abstract object definition is the System.Type.FullName of the target instance. This method is typically used when objects are instantiated outside the control of a developer, for example when ASP.NET instantiates web controls and when a WinForm application creates UserControls.

void ConfigureObject(object target, string name): Offers the same functionality as the previously listed Configure method but uses a named object definition instead of using the type's full name.

Ik denk dat je dus om het probleem heen kunt werken door met AspectSharp een "after-method advice" te koppelen aan de lege constructors op je domein objecten (die NHibernate gebruikt) mbv. een attribute (annotation) of iets dergelijks. In die after advice wordt dan het desbetreffende object bekendgemaakt aan de application context, zodat deze alle DI kan uitvoeren.

[-FoX-]

paulgielens schreef op zondag 25 juni 2006 @ 09:42:
Misschien is het een idee om een voorbeeld te geven waar Spring 2 het verschil maakt?

Blog die dergelijke functionaliteit mooi aantoont: Spring 2.0 AOP - Spruce Up Your Domain Model

[Scare360]

-FoX- schreef op dinsdag 04 juli 2006 @ 10:30:
[...]

Blog die dergelijke functionaliteit mooi aantoont: Spring 2.0 AOP - Spruce Up Your Domain Model

Dank je!

Dit kan natuurlijk nu ook al met Spring. Of je nu annotations (of attributes/.NET) gebruikt @Configurable("trade") of (InterestRateDao) ctx.GetObject ("trade");

[Alarmnummer]

paulgielens schreef op zaterdag 08 juli 2006 @ 11:06:
[...]


Dank je!

Dit kan natuurlijk nu ook al met Spring. Of je nu annotations (of attributes/.NET) gebruikt @Configurable("trade") of (InterestRateDao) ctx.GetObject ("trade");

Je moet dan wel aan de context kunnen komen. En verder: bean ophalen op deze manier uit de context is geen DI maar Service Locator en dat vind ik imho vrij hard zuigen aangezien je dan een extra verantwoordelijkheid bij het object neer legt: het kiezen van de juiste dependency. Dit zie ik ook terug bij EJB3 en krijg ik toch wel een beetje een naar gevoel bij.

[Scare360]

Alarmnummer schreef op zaterdag 08 juli 2006 @ 12:29:
Je moet dan wel aan de context kunnen komen. En verder: bean ophalen op deze manier uit de context is geen DI maar Service Locator en dat vind ik imho vrij hard zuigen aangezien je dan een extra verantwoordelijkheid bij het object neer legt: het kiezen van de juiste dependency. Dit zie ik ook terug bij EJB3 en krijg ik toch wel een beetje een naar gevoel bij.

Of je nu een afhankelijkheid naar de annotation package of de spring.core package hebt... of je een string configuratie verpakt in een annotation of een argument... of je nu impliciet de verantwoordelijk aan de object toekent door een annotation of expliciet via IApplicationContext.

Fowler: The key difference is that with a Service Locator every user of a service has a dependency to the locator. The locator can hide dependencies to other implementations, but you do need to see the locator. So the decision between locator and injector depends on whether that dependency is a problem.

Ik zou het zelf niet beter kunnen verwoorden. Oftewel een kwestie van smaak. Neemt niet weg dat deze feature zeer welkom is (ook in Spring.NET).

[Alarmnummer]

paulgielens schreef op zaterdag 08 juli 2006 @ 22:52:
[...]


Of je nu een afhankelijkheid naar de annotation package of de spring.core package hebt... of je een string configuratie verpakt in een annotation of een argument... of je nu impliciet de verantwoordelijk aan de object toekent door een annotation of expliciet via IApplicationContext.

Fowler: The key difference is that with a Service Locator every user of a service hasa dependency to the locator. The locator can hide dependencies to other implementations, but you do need to see the locator. So the decision between locator and injector depends on whether that dependency is a problem.

Ik zou het zelf niet beter kunnen verwoorden. Oftewel een kwestie van smaak. Neemt niet weg dat deze feature zeer welkom is (ook in Spring.NET).

De scope van een annotation is iedere instantie van de class. Oftwel iedere instance van die class zal dezelfde dependencies krijgen (tenzij het een andere 'context' krijgt waar hij zijn informatie uit kan peuteren).

De scope van een injected dependency in Spring is een instance.(is ook metadata maar dan op bean nivo): count the differences.. Ik heb het stuk van fowler ook gelezen maar ik denk dat hij het hier toch niet bij het rechte end heeft of dat hij hier genuanceerd wil zijn.

Service locators zijn imho nog steeds inferieur tov di..

Service locator is bv net zo beperkend als werken van een abstracte class ipv een interface.. En we weten intussen allemaal dat abstracte classes meestal een 'smell' zijn in je systeem.

[ Voor 32% gewijzigd door Alarmnummer op 09-07-2006 09:19 ]

[Scare360]

Alarmnummer schreef op zaterdag 08 juli 2006 @ 23:49:
De scope van een annotation is iedere instantie van de class. Oftwel iedere instance van die class zal dezelfde dependencies krijgen (tenzij het een andere 'context' krijgt waar hij zijn informatie uit kan peuteren).

Kan je een voorbeeld geven waarbij de context van belang is... bv ClassA---association-->ClassB waarbij ClassA in een andere context leeft dan ClassB?