[ALG] Domein objecten of BusinessObjecten of ...

donderdag 9 maart 2006 09:41

-= Tja =-

Cuball schreef op donderdag 09 maart 2006 @ 09:01:
Nu kan je dat volgens mij op 2 manieren doen (zullen er nog wel meer zijn). Stel je hebt een controller en de gebruiker heeft net een bod ingegeven, nu moet gecontroleerd worden of dit bod wel geldis is:
In onderstaande code heb ik de business logica in het domein object item geplaatst, de methode addBid controleert of het bod wel geplaatst kan worden volgens de business. De methode addBid heeft wel geen itemDAO tot zijn beschikking (omdat er geen afhankelijk heid mag zijn in het domein object aan de DAO laag (unit testen wordt er een stuk beter op), daarom wordt eerst maxBid

Domain objecten mogen zeker wel toegang hebben tot je data laag. Bij Spring 2 zul je ook zien dat het nu ineens erg eenvoudig gaat worden om dependencies in je domain objecten krijgen. Verder hoeven er vaak geen save calls van domain objecten naar de datalaag gedaan te worden, omdat alle domein objecten (alle entities) gebonden zijn aan een sessie (hibernate sessie). Dan hoef je alleen maar objecten te attachen/removen van je sessie, en die zorgt er wel voor dat de db ermee gesynchroniseerd wordt.

Een andere methode is het gebruik van BusinessObjecten, hierbij hebben deze business objecten wel toegang tot de DAO objecten.
Java:
1
2
3
4
5
6
7
8
9
action() {
  Bid bid = getnewBidFromFormOrWhatever(); 
  try {
    itemBO.addBid(item,bid);
  catch (BusinessException be) {
    //
  }
return to jsp
}

Yep.. zoiets krijg je dan. Maar als je de reachability van Hibernate goed instelt, dan hoef je dus bijna geen save calls meer te doen. Ik wil trouwens binnenkort ook een artikel gaan schrijven over reachability van Hibernate.

Ik heb het altijd volgens de laatste methode gedaan, maar ik zie in verschillende boeken (bv hiberante in action) dat velen logica in de domein objecten plaatsten, zoals ik het gebruik zijn de domein objecten eerder Value objecten, het zijn objecten die enkel data bevatten uit databank, maar zullen nooit een BusinessException opwerpen...

Het is denk ik verstandig om te realiseren dat er meerdere definities zijn voor een term:
ValueObjecten zijn objecten zonder identitieit, bv geld, of een adres. Het maakt niet uit welk geld object je krijgt, of welk adres object, als de inhoud er maar goed van is.
Entiteiten zijn objecten met identiteit. Jouw vrouw die kan niet vervangen worden door een ander object met exact dezelfde eigenschappen (dan heb je ineens een andere vrouw). Dus daar doet de identiteit er wel toe.

Ben ik nu verkeerd bezig ? Of hoe zien jullie dit ?

Volgens mij zijn velen er nog niet echt uit. Wij (bij JTeam) gaan binnenkort aan de slag met Spring 2 en we gaan kijken hoe we dus een echt rijk domain model binnen onze applicaties kunnen realiseren. Op dit moment gebruiken we meer een Transaction Script achtige structuur (zie PEAA van Fowler en zoek maar eens op Anemic Domain Model) en vooral bij complexe domeinen is dit toch minder prettig (en minder oo). Ik denk dat het merendeel van de bedrijven helemaal nog niet experimenteert met rijke domain modellen, dus zo gek is je onzekerheid nog niet.

Acties:

donderdag 9 maart 2006 09:50

Topicstarter

Alarmnummer schreef op donderdag 09 maart 2006 @ 09:18:

[...]

Yep.. zoiets krijg je dan. Maar als je de reachability van Hibernate goed insteld, dan hoef je dus bijna geen save calls meer te doen. Ik wil trouwens binnenkort ook een artikel gaan schrijven over reachability van Hibernate.

In het voorbeelde dat ik gaf gebruik ik een object itemBO van het type ItemBO (een extra object die in feite enkel business methods heeft maar geen staat). Ik veronderstel dat je bedoelt dat itemBO in het voorbeelde ook van het type Item was en dat ik daar dan toch itemDAO objecten kan in gebruiken?

Maar hoe werkt dit dan, als ik een entiteit ophaal via Hibernate bv een Item, hoe kan ik er dan voor zorgen van zodra ik een Item object heb dat er daar een ItemDAO referentie inzit ? Of kan spring2 van zodra een hibernate persistent object ophaalt daar dan een ItemDAO injecteren ? Ik zie deze mogelijkheid alvast niet in Spring 1.x

"Live as if you were to die tomorrow. Learn as if you were to live forever"

Acties:

donderdag 9 maart 2006 09:59

-= Tja =-

Cuball schreef op donderdag 09 maart 2006 @ 09:41:
[...]
In het voorbeelde dat ik gaf gebruik ik een object itemBO van het type ItemBO (een extra object die in feite enkel business methods heeft maar geen staat).

Ze zijn ook wel bekend onder de naam 'Manager' of 'Service'.

Ik veronderstel dat je bedoelt dat itemBO in het voorbeelde ook van het type Item was en dat ik daar dan toch itemDAO objecten kan in gebruiken?

Aangezien je managers/bo`s meestal stateless zijn, maak je ze vaak een keer aan en injecteer je daar gewoon je dependencies in. Ja dus.

Maar hoe werkt dit dan, als ik een entiteit ophaal via Hibernate bv een Item, hoe kan ik er dan voor zorgen van zodra ik een Item object heb dat er daar een ItemDAO referentie inzit ? Of kan spring2 van zodra een hibernate persistent object ophaalt daar dan een ItemDAO injecteren ? Ik zie deze mogelijkheid alvast niet in Spring 1.x

Het gebeurt via de classloader. Op het moment dat een domain object wordt aangemaakt (bv een Persoon) dan zal na het aanmaken, gekeken worden in de ApplicationContext of daar een template definitie staat voor die bean: zo ja, dan worden de dependencies erin geinjecteerd.

vb.

Java:

package foo.bar;

class Persoon{
   private PersoonDao;

  ...getters en setters
}

XML:

<bean id="persoonDao"
          class="HibernatePersoonDao"/>

<bean id="foo.bar.Persoon"><!-- de template -->
     <property name="persoonDao" ref="persoonDao"/>
</bean>

Iedere persoon die nu aangemaakt gaat worden, zal nadat het is aangemaakt is, voorzien zijn van een PersoonDao. Het maakt dan verder niet uit wie dit object aanmaakt: de dependencies komen er gewoon in terecht.

[ Voor 22% gewijzigd door Alarmnummer op 09-03-2006 09:53 ]

Acties:

donderdag 9 maart 2006 10:05

Topicstarter

Alarmnummer schreef op donderdag 09 maart 2006 @ 09:50:

Het gebeurt via de classloader. Op het moment dat een domain object wordt aangemaakt (bv een Persoon) dan zal na het aanmaken, gekeken worden in de ApplicationContext of daar een template definitie staat voor die bean: zo ja, dan worden de dependencies erin geinjecteerd.

[...]

Iedere persoon die nu aangemaakt gaat worden, zal nadat het is aangemaakt is, voorzien zijn van een PersoonDao. Het maakt dan verder niet uit wie dit object aanmaakt: de dependencies komen er gewoon in terecht.

Dit is verondestel ik enkel mogelijk via Spring 2 want dergelijk systeem heb ik toch niet gezien in Spring 1.x ? Lukt dit zelfs als je gewoon in je code : Persoon persoon= new Persoon(); dan wordt daar automatisch een PersoonDao geinjecteerd ? mooi zeg, toch eens moeten kijken naar Srping 2

Sorry voor de vele vragen en onduidelijkheden, maar hoe beslis je dan of een methode in je Domein object komt (addBid) of al dan niet in je een stateless Service 'Manager' object ?

"Live as if you were to die tomorrow. Learn as if you were to live forever"

Acties:

donderdag 9 maart 2006 12:16

-= Tja =-

Cuball schreef op donderdag 09 maart 2006 @ 09:59:
[...]

Dit is verondestel ik enkel mogelijk via Spring 2 want dergelijk systeem heb ik toch niet gezien in Spring 1.x ? Lukt dit zelfs als je gewoon in je code : Persoon persoon= new Persoon(); dan wordt daar automatisch een PersoonDao geinjecteerd ? mooi zeg, toch eens moeten kijken naar Srping 2

Alleen vanaf Spring 2. Ik denk dat vanaf Spring 2 ook echt de discussies los gaan barsten over rijke domain modellen. Op het forum zijn ze er nu al, maar Spring 1 maakt het niet bepaald eenvoudig om met een rijk domain model te werken doordat het nagenoeg onmogelijk is om aan dependencies in je entities/value objects te krijgen.

Sorry voor de vele vragen en onduidelijkheden, maar hoe beslis je dan of een methode in je Domein object komt (addBid) of al dan niet in je een stateless Service 'Manager' object ?

Hmm tja. wanneer beslis jij bij normaal oo programmeren of het wel zo handig is om een methode in een bepaalde class te plaatsen of het een zelfstandige eenheid te maken? Als de handeling erg complex is, of je wilt de logica gaan groeperen binnen een enkel object omdat het anders zo versnipperd ligt over je class hierarchie, dan ga je een logica achtig object maken. Ik denk dat hierover nog heel veel discussies gevoerd gaan worden, ik denk dat we in eerst instantie veel 'te' volle domain objecten gaan zien omdat het dan echt een rijk domain model is: een soortement van overreactie. Check trouwens anders Domain Driven Design (boek dat dus hier diep op in gaat).

Je moet trouwens niet vergeten dat een taak van je BO`s wel moet blijven bestaan: de facade. Een facade zorgt voor een 'eenvoudige' ingang tot de internals van je systeem. Meestal zijn de methodes in de facade een op een terug te vinden bij een bepaalde usecase (bv fire(employee)). Deze taak moeten ze blijven vervullen (sowieso voor transacties/security oogpunt) maar ook omdat het werken met zo`n systeem veel eenvoudiger is (laat de facade maar uitzoeken naar welke objecten hij de taak moet delegeren (is een implementatie detail en die hoort niet zichtbaar te zijn in bv de presentation layer)).

[edit]
Grappige gedachte: toen we vanaf procedureel naar oo zijn gegaan, dus van behaviour en state gescheiden structuren naar objecten (dus state en behaviour gecombineerd) zijn gegaan, zijn we eerst doorgeslagen naar te volle objecten. Later zijn we in aanraking gekomen met design patterns en eindelijk in hebben gezien dat logica niet altijd in een object thuis hoort maar soms beter in andere objecten geplaatst kan worden.

Dezelfde beweging zie je nu binnen de domain layer. Je domain layer is op dit moment meestal een transaction script achtige structuur: dus state in de domain objects, en behaviour in de managers. Met Spring 2 zullen we eerst doorslaan naar te volle domain objecten, en straks zullen we weer een belans vinden tussen waar behaviour thuis gaat horen. Ik hoop alleen niet dat het zo lang gaat duren als de 1e keer

if we don't understand the past we are bound to repeat it

[ Voor 34% gewijzigd door Alarmnummer op 09-03-2006 10:23 ]

Acties:

donderdag 9 maart 2006 12:26

Topicstarter

héhé hopelijk duurt het inderdaad niet zo lang :-)

ik zal es het boeke Domain Driven Development lezen en af en toe de draadjes op het Spring forum overlopen. Ik vraag me trouwens af of dit in de .NET wereld ook voorkomt...

"Live as if you were to die tomorrow. Learn as if you were to live forever"

Acties:

donderdag 9 maart 2006 12:46

In de .NET wereld zit je vooral met het probleem dat de meeste mensen focussen op DataSets.

https://fgheysels.github.io/

Acties:

pjvandesande

GC.Collect(head);

whoami schreef op donderdag 09 maart 2006 @ 12:26:
In de .NET wereld zit je vooral met het probleem dat de meeste mensen focussen op DataSets.

Alleen die VB6-hippies die overstappen

donderdag 9 maart 2006 15:52

Acties:

donderdag 9 maart 2006 16:09

Topicstarter

Alarmnummer schreef op donderdag 09 maart 2006 @ 10:05:
[...]

Alleen vanaf Spring 2. Ik denk dat vanaf Spring 2 ook echt de discussies los gaan barsten over rijke domain modellen. Op het forum zijn ze er nu al, maar Spring 1 maakt het niet bepaald eenvoudig om met een rijk domain model te werken doordat het nagenoeg onmogelijk is om aan dependencies in je entities/value objects te krijgen.

Wat ik me nog afvroeg (nog wel meerdere zaken hoor

) als je dan zo'n rijk domein model hebt, gebruik je die objecten dan tot in je prestatie laag? (bv om van Item een lijst van bids te tonen) of vorm je die onderweg nog es om naar eenvoudige "Value Objecten" zonder business logica erin ?

Ik kan me voorstellen als de prestatie van de applicatie door niet ontwikkelaars worden gedaan hier problemen kunnen ontstaan als er vanuit de prestatie laag dan een business methode van je domein object wordt opgeroepen met alle gevolgen vandien?.

[ Voor 5% gewijzigd door Cuball op 09-03-2006 16:00 ]

"Live as if you were to die tomorrow. Learn as if you were to live forever"

Acties:

zondag 12 maart 2006 21:21

Cuball schreef op donderdag 09 maart 2006 @ 15:52:
[...]

Wat ik me nog afvroeg (nog wel meerdere zaken hoor ) als je dan zo'n rijk domein model hebt, gebruik je die objecten dan tot in je prestatie laag? (bv om van Item een lijst van bids te tonen) of vorm je die onderweg nog es om naar eenvoudige "Value Objecten" zonder business logica erin ?

Ik denk dat dit vooral afhangt van de eisen van jouw applicatie.
Ik zelf heb er in bepaalde gevallen geen problemen mee om in je presentatie laag gebruik te maken van je domein - objecten (business objecten)

https://fgheysels.github.io/

Acties:

Eelke Spaak

- Vlad -

whoami schreef op donderdag 09 maart 2006 @ 16:09:
[...]

Ik denk dat dit vooral afhangt van de eisen van jouw applicatie.
Ik zelf heb er in bepaalde gevallen geen problemen mee om in je presentatie laag gebruik te maken van je domein - objecten (business objecten)

Ik heb zelf een tijdje gedacht dat het 'lelijk' was om domein objecten te gebruiken in de presentatielaag, maar dat kwam vooral omdat mijn presentatie een remote Swing client, en dus een andere VM was. Dan maakte ik steeds data-transfer-objects voor de velden die ik nodig denkte te hebben in mijn presentatielaag. Echter, eigenlijk (realiseer ik me nu) is dit gewoon nutteloos werk en zijn de domein objecten prima te gebruiken in de presentatielaag.

Sterker nog, ik vraag me af of de scheiding tussen lagen niet überhaupt een beetje te ver is doorgevoerd. Als voorbeeld: ik heb een grote applicatie gemaakt met grofweg de volgende onderscheiding: domein objecten - DAO's - business layer - presentatie. Dit leek me zinnig omdat ik dan de DAO's eventueel nog kon vervangen als ik af wilde van Hibernate. Maar wat bleek: zeker de helft van de business methods waren gewoon simpele wrappers voor die DAO methods: findAllUsers() ging gewoon naar userDao.findAll() bv. Omdat dit wederom veel nutteloos werk oplevert lijkt mij een scheiding DAO - business layer kunstmatig en niet nodig. Een wrapper van bepaalde DAO-functionaliteit (een HibernateDao klasse bijvoorbeeld) is wel handig, maar de concrete DAO-klassen kunnen net zo goed ook business klassen worden en dus business methods bevatten.

TheStreme - Share anything with anyone

zondag 12 maart 2006 22:15

Acties:

maandag 13 maart 2006 09:15

Topicstarter

Eelke Spaak schreef op zondag 12 maart 2006 @ 21:21:
[...]
Maar wat bleek: zeker de helft van de business methods waren gewoon simpele wrappers voor die DAO methods: findAllUsers() ging gewoon naar userDao.findAll() bv. Omdat dit wederom veel nutteloos werk oplevert lijkt mij een scheiding DAO - business layer kunstmatig en niet nodig.

dat is nu net ook het gevoel dat ik heb veelal van mijn business methodes die ik schrijf, het zijn gewoon weg een wrappers om hetzelfde aan te roepen in de DAO laag. Akkoord, af en toe komt daar wel wat logica bij te kijken bij de use case business logica, maar toch ook veel het gewoon doorgeven naar dezelfde functie in een andere laag.

Maar ik ga het boek domain driven development toch es moeten aanschaffen, ik had sinds kort er nooit aan gedacht om zelf de DAO objecten in men domein objecten te gebruiken en daar ook effectief logica in onder te brengen... het is toch een andere kijk op het design van een applicatie...

"Live as if you were to die tomorrow. Learn as if you were to live forever"

Acties:

maandag 13 maart 2006 09:20

-= Tja =-

Cuball schreef op donderdag 09 maart 2006 @ 15:52:
[...]

Wat ik me nog afvroeg (nog wel meerdere zaken hoor ) als je dan zo'n rijk domein model hebt, gebruik je die objecten dan tot in je prestatie laag? (bv om van Item een lijst van bids te tonen) of vorm je die onderweg nog es om naar eenvoudige "Value Objecten" zonder business logica erin ?

Als je op dezelfde machine blijft, dan pass ik mijn domain objecten gewoon door naar de presentation layer. Alleen als er sprake is van remoting dan kieper ik de inhoud van domain objecten in data transfer objecten (DTO`s).

Ik kan me voorstellen als de prestatie van de applicatie door niet ontwikkelaars worden gedaan hier problemen kunnen ontstaan als er vanuit de prestatie laag dan een business methode van je domein object wordt opgeroepen met alle gevolgen vandien?.

In principe mag niemand de business methodes van je domain objecten aanroepen behalve de business facade (dus de ingang van je business layer). Hij is verantwoordelijk voor:
-of het implementeren van de business logic (anemic domain model/transaction script)
-of het delegeren van de taken naar de juiste domain objecten/services (zie ddd)

Je presentatie laag mag alleen maar getters aanroepen.

Acties:

woensdag 15 maart 2006 14:47

-= Tja =-

Eelke Spaak schreef op zondag 12 maart 2006 @ 21:21:
[...]

Ik heb zelf een tijdje gedacht dat het 'lelijk' was om domein objecten te gebruiken in de presentatielaag, maar dat kwam vooral omdat mijn presentatie een remote Swing client, en dus een andere VM was. Dan maakte ik steeds data-transfer-objects voor de velden die ik nodig denkte te hebben in mijn presentatielaag. Echter, eigenlijk (realiseer ik me nu) is dit gewoon nutteloos werk en zijn de domein objecten prima te gebruiken in de presentatielaag.

Sterker nog, ik vraag me af of de scheiding tussen lagen niet überhaupt een beetje te ver is doorgevoerd. Als voorbeeld: ik heb een grote applicatie gemaakt met grofweg de volgende onderscheiding: domein objecten - DAO's - business layer - presentatie. Dit leek me zinnig omdat ik dan de DAO's eventueel nog kon vervangen als ik af wilde van Hibernate.

Van or mapper wisselen is toch een illusie. Er zit zoveel onzichtbare functionaliteit waar je dus al van uit gaat dat je niet eenvoudig kunt wisselen.

Maar wat bleek: zeker de helft van de business methods waren gewoon simpele wrappers voor die DAO methods: findAllUsers() ging gewoon naar userDao.findAll() bv. Omdat dit wederom veel nutteloos werk oplevert lijkt mij een scheiding DAO - business layer kunstmatig en niet nodig.

Zo lijkt het wel, maar zo is het niet. Je business laag heeft namelijk nog een andere taak:
coordineren van transacties
afdwingen van security.

Daarom vraag ik me dus af hoe handig het is om direct access te geven naar je DAO`s aangezien je dan problemen gaat krijgen om transacties/security te coordineren.

Een wrapper van bepaalde DAO-functionaliteit (een HibernateDao klasse bijvoorbeeld) is wel handig, maar de concrete DAO-klassen kunnen net zo goed ook business klassen worden en dus business methods bevatten.

Ben ik niet mee eens. Als je wat serieuzere logica gaat krijgen dan is een scheiding wel fijn: je houd je troep bij elkaar. Bij de DAO`s kan ik db gerelateerde functionaliteit aantreffen, en bij de business layer kan ik business gerelateerde functionaliteit aantreffen (met eventueel calls naar bv dao`s). Ik werk zelf daarom wel liever met een aparte business laag. Alleen als de applicatie heel eenvoudig is, dan zou je eens een shortcut kunnen proberen.. maar anders...

[edit]
Verder is het testen meestal ook eenvoudiger als je meer objecten krijgt. Je kunt dan eenvoudiger collaborators vervangen door mock/stub implementaties.

[ Voor 6% gewijzigd door Alarmnummer op 13-03-2006 09:40 ]

Acties:

Antediluvian

Eelke Spaak schreef op zondag 12 maart 2006 @ 21:21:
Maar wat bleek: zeker de helft van de business methods waren gewoon simpele wrappers voor die DAO methods: findAllUsers() ging gewoon naar userDao.findAll() bv.

Zodra je met verschillende storage systemen werkt komt dit bv al bijna niet meer voor.

Stel dat je van verschillende entities een search (bv lucene) index wil hebben.
Dan is het juist aan de service layer om die beslissen te maken:

Java:

public void save(User user) {
    userDao.save(user); 
    userIndex.add(user);
}

public Collection seachByName(String username){
    //not return userDao.findByName(username);
    return userIndex.seach(username);
}

woensdag 15 maart 2006 14:49

Acties:

woensdag 15 maart 2006 15:30

Alarmnummer schreef op maandag 13 maart 2006 @ 09:20:
[...]

Van or mapper wisselen is toch een illusie. Er zit zoveel onzichtbare functionaliteit waar je dus al van uit gaat dat je niet eenvoudig kunt wisselen.

Da's idd een illusie, en ik vraag me trouwens af waarom je dat zou willen doen.
Waarom zou je er trouwens rekening moeten mee houden. Hoeveel keer komt het voor dat je plots zegt, goh, ik zou wel eens een andere O/R mapper willen gebruiken.

Je business laag heeft namelijk nog een andere taak:
coordineren van transacties
afdwingen van security.

Is dat de laag van je business-laag ? Ik vind van niet.
Het kan hooguit de taak zijn van je business-facade laag. Het is maw imho de taak van de laag die je business objecten gebruikt (dat kan eigenlijk ook de client zijn).
Stel dat ik een Windows applicatie heb, die direct gebruik maakt van m'n Business Objecten, dan is het de taak van m'n Windows applicatie om de transacties te coördineren.

[ Voor 34% gewijzigd door whoami op 15-03-2006 14:50 ]

https://fgheysels.github.io/

Acties:

woensdag 15 maart 2006 15:32

Topicstarter

whoami schreef op woensdag 15 maart 2006 @ 14:49:

Is dat de laag van je business-laag ? Ik vind van niet.
Het kan hooguit de taak zijn van je business-facade laag. Het is maw imho de taak van de laag die je business objecten gebruikt (dat kan eigenlijk ook de client zijn).
Stel dat ik een Windows applicatie heb, die direct gebruik maakt van m'n Business Objecten, dan is het de taak van m'n Windows applicatie om de transacties te coördineren.

ik kan wel in je redenering komen, maar jou zou dus de verantwoordelijkheid bij je applicatie leggen die de business gebruikt of transactie al dan niet slaagt? Stel ik heb een business methode:

schrijfOver(vanRekening, naarRekening, bedrag);

deze bestaat bv uit 2 verschillende oproepen uit ander business objecten:

haalVan(vanRekening, bedrag);
schrijfOp(naarRekening, bedrag);

volgens mij is een transactie nu toch deel van de Business. Je applicatie roept dan enkel schrijfOver op en dit lukt voor hem of niet, maar of dat nu via transacties of welk manier ook verzekerd wordt maakt hem toch niet uit ?

"Live as if you were to die tomorrow. Learn as if you were to live forever"

Acties:

woensdag 15 maart 2006 15:40

Die schrijfOver method is dan eigenlijk een BusinessFacade method, en daar ga je die transactie idd gaan coordineren.

https://fgheysels.github.io/

Acties:

woensdag 15 maart 2006 16:04

Topicstarter

whoami schreef op woensdag 15 maart 2006 @ 15:32:
Die schrijfOver method is dan eigenlijk een BusinessFacade method, en daar ga je die transactie idd gaan coordineren.

klopt, is volgens mij de betere oplossing. Toch een stuk beter dan de verschillende oproepen van de andere Business methodes in je applicatie te gaan coordineren en beheren.

"Live as if you were to die tomorrow. Learn as if you were to live forever"

Acties: