[alg] plaatsing business logic.

[Alarmnummer]

Een vraag waar ik al een tijdje mee worstel is waar de business logic geplaatst moet worden. Laat ik eerst even duidelijk maken dat dit dus in de business/domain layer plaats vind. Hierover is geen onduidelijkheid.

Maar plaats je de business logica bij het gedrag van een domein object in, of maak je een apart BusinessLogic/Service achtig object aan, waarmee je domein objecten reduceert tot records.

[kasper_vk]

Tja, volgens mij is dat maar net wat het meest praktisch is in een specifieke case.

Ik werk (qua java) de laatste tijd veel met Struts en van daaruit wordt je dus gedwongen om met aparte Action klasses aan de gang te gaan.
Daar plaats ik mijn BL, waardoor in mijn geval de domeinklassen idd tot records gereduceerd worden.

Maar ik heb ook vraagtekens bij deze aanpak, omdat je dus erg makkelijk domeingedrag in de actions neigt te stoppen.

Het gaat bij mij zelfs zover dat ik momenteel een opzet aan het uitwerken ben waarbij er dus geen concrete domein-klassen zijn, maar de actions werken met record-objecten. Eigelijk bevat dan de buisiness logic dus alleen maar Action / Service klassen.

[ Voor 23% gewijzigd door kasper_vk op 13-09-2004 13:12 ]

[Alarmnummer]

kasper_vk schreef op 13 september 2004 @ 13:10:
Tja, volgens mij is dat maar net wat het meest praktisch is in een specifieke case.

Maar ik heb ook vraagtekens bij deze aanpak, omdat je dus erg makkelijk domeingedrag in de actions neigt te stoppen.

Je kunt toch de call van die weblayer-action forwarden naar de service? Op die manier hou je tenminste al het domein gedrag bij elkaar. Of doel je meer op het feit dat dit niet gedaan wordt omdat het zoveel werk-overhead met zich meebrengt. Je moet dan niet alleen de action maken, maar dan ook nog eens de service.

Ik heb om een andere reden mijn vraagtekens bij deze aanpak (dus logica van data te scheiden) omdat het mogelijk is om objecten in een inconsistente toestand achter te laten. Verder is het een hele andere manier van werken dan ik gewend ben. Ik ben op zich best bereid om een andere werkwijze voor dit soort problematiek aan te leren, maar dan wil ik wel argumenten hiervoor hebben.

Dus wat is het voordeel om de logica volledig uit domein objecten te trekken en onder te brengen in Service/BusinessLogic achtige objecten

[-FoX-]

In mijn designs probeer ik meestal de business logica achter een bepaalde (session)facade te stoppen. Hierdoor functioneert mijn facade als enig aanspreekpunt voor de client-objecten.

Hierdoor komt het "Separation of Concerns" paradigma ook heel mooi naar boven.

Het is trouwens "fout" om je BL in je Struts Action-classes te stoppen. Je kan je BL beter achter een bepaalde layer stoppen en in je action-classes gewoon je facade aanspreken (die je request dan weer door zal delegeren naar de juiste BL).

[Alarmnummer]

-FoX- schreef op 13 september 2004 @ 13:23:
In mijn designs probeer ik meestal de business logica achter een bepaalde (session)facade te stoppen. Hierdoor functioneert mijn facade als enig aanspreekpunt voor de client-objecten.

Dat ben ik met je eens, maar het is geen antwoord op mijn vraag. De vraag is of je nog logica bij de 'entiteit' laat zitten, of dat je alles gaat verplaatsen naar de 'Service' (die eventueel onder een session facade kan zitten). Dus wil je entiteit objecten zonder eigen of met eigen gedrag., dus echte objecten, of record-achtige objecten.

Hierdoor komt het "Separation of Concerns" paradigma ook heel mooi naar boven.

Ben ik niet met je eens. Onder object georienteerd programmeren wordt meestal verstaan het onderbrengen van data en logica onder objecten. Ik zie de toegevoegde waarde niet om dit nu ineens te gaan scheiden.

Waar jij op doelt (denk ik) is dat je bij je session facade`s (ik hoop echt niet bij je sessions) het duidelijke onderscheid ziet tussen allerlei aspecten zoals transacties,concurrency en de business layer.

[ Voor 5% gewijzigd door Alarmnummer op 13-09-2004 13:35 ]

[kasper_vk]

Alarmnummer schreef op 13 september 2004 @ 13:19:
[...]

Je kunt toch de call van die weblayer-action forwarden naar de service? Op die manier hou je tenminste al het domein gedrag bij elkaar. Of doel je meer op het feit dat dit niet gedaan wordt omdat het zoveel werk-overhead met zich meebrengt. Je moet dan niet alleen de action maken, maar dan ook nog eens de service.

Inderdaad, het maken van een action én een service is dan veel overhead. Aan de andere kant: het actions object functioneert als eventhandler, waardoor het in de App. Logic thuishoort. Het zou dan eigelijk alleen maar de brug moeten vormen tussen UI en BL, waarin de BL dus

• ofwel een aparte serviceklasse is
• ofwel uitgevoerd is als methoden van domeinobjecten

Ik heb om een andere reden mijn vraagtekens bij deze aanpak (dus logica van data te scheiden) omdat het mogelijk is om objecten in een inconsistente toestand achter te laten. Verder is het een hele andere manier van werken dan ik gewend ben. Ik ben op zich best bereid om een andere werkwijze voor dit soort problematiek aan te leren, maar dan wil ik wel argumenten hiervoor hebben.

Dit ben ik enerzijds wel met je eens, maar anderzijds is het vaak zo dat de domeinobjecten nauwelijks meer doen dan de records in een database representeren. In dat geval is het de database die de consistentie waarborgt en heeft het vrij weinig nut om gedrag toe te kennen aan 'records'.
En dus ook niet aan de objecten die die records representeren; zelfs niet als je eigelijk OO aan het toepassen bent.

Dus wat is het voordeel om de logica volledig uit domein objecten te trekken en onder te brengen in Service/BusinessLogic achtige objecten

In het geval dat je domeinklassen niets anders zijn dan een representatie zouden zijn van records uit de database: je zou de domeinklassen kunnen genereren of uiterst eenvoudig kunnen houden en de logica ligt dan dus altijd op 1 centrale plaats. Het voordeel is dus de eenvoudigheid van je systeem.
Nogmaals: alleen als de case deze eenvoud toelaat.

[kasper_vk]

Alarmnummer schreef op 13 september 2004 @ 13:34:
...
Dus wil je entiteit objecten zonder eigen of met eigen gedrag., dus echte objecten, of record-achtige objecten.

...

Volgens mij zit het antwoord al in je vraag:

Representeerd een klasse een (of meerdere) record(s) uit een database, dan ken je geen gedrag toe aan de klasse. Waarom niet? --> Omdat een record geen eigen gedrag heeft. Het veranderd wel, maar dat is geen gedrag van het record, maar van de database als geheel. Het is de database die d.m.v. rules en restricties zijn eigen consistente toestand (en de veranderingen daarin: 'gedrag') moet waarborgen, niet een daarvan afgeleid object.

Representeert een klasse niet iets uit een database (of andere persistente opslag) dan plaats je wel het gedrag in die klasse.

[-FoX-]

Alarmnummer schreef op 13 september 2004 @ 13:34:
[...]
Dat ben ik met je eens, maar het is geen antwoord op mijn vraag. De vraag is of je nog logica bij de 'entiteit' laat zitten, of dat je alles gaat verplaatsen naar de 'Service' (die eventueel onder een session facade kan zitten). Dus wil je entiteit objecten zonder eigen of met eigen gedrag., dus echte objecten, of record-achtige objecten.

De vraag kan misschien ook anders worden gesteld. Waarom wil jij perse gedrag bij je entiteiten plaatsen?

Ik opteer er meestal wel voor om mijn objecten zonder gedrag te instantiëren, gewoon om de simpele reden dat ik nogal eens durf/wil gebruik maken van een ORM. Op deze manier plaats ik de ORM-services onder de DAO-layer en gebruik ik mijn objecten (zonder gedrag) via de DAO-layer en dus door de ORM.

[Verwijderd]

naar mijn mening is dit hetzelfde als vragen of stored procedures kunnen/mogen. Is een database meer dan persistente opslag of niet?

Ik ben de mening toegedaan dat je CMP's (bijvoorbeeld, mag ook een JDO/Hibernate/... object zijn) enkel getters en setters hebben zonder business logic.
Als je SQL gebruikt schrijf je meestal gewoon queries die je in (cached) preparedstatements stopt.
Dus met SQL heb je precies minder de neiging/mogelijkheid om BL dichtbij je database te plaatsen, maar OR-mappers geven die mogelijkheid die in mijn ogen niet gebruikt zou mogen worden.

De business logic zit in aparte BL klassen die opgeroepen worden door de session layer waar de security grondig gecheckt wordt (achter de session layer, maar niet als deel van de BL).

offtopic:
tja, misschien nogal een opvallend JAVA uitleg, maar met webservices als sessionlayer en ObjectSpaces/NHibernate (misschien ooit) als OR-mapper is het ook van toepassing voor .NET

[zneek]

Ik vind een van de voordelen van aparte BL objecten dat je business logic die gaat over meer dan 1 'record' object kunt opnemen. Je kunt combinaties van entiteit objecten bewerken, valideren en vervolgens opslaan (of juist niet).

Wanneer je alle logica in de entity objecten stopt krijg je onherroepelijk toch objecten die daarbuiten een stuk BL in zich hebben, omdat je nou eenmaal niet altijd met 1 entity aan het werk bent.

[Infinitive]

zneek schreef op 13 september 2004 @ 15:15:
Ik vind een van de voordelen van aparte BL objecten dat je business logic die gaat over meer dan 1 'record' object kunt opnemen. Je kunt combinaties van entiteit objecten bewerken, valideren en vervolgens opslaan (of juist niet).

Welk object heeft dan op dat moment de verantwoordelijkheid voor het aanmaken van nieuwe BL objecten en DAOs?

Bijv. geef je de Primary Key mee aan je BL object zodat hij de corresponderende DAO(s) kan laden vanuit de DAL? Maar hoe maak je dan een nieuw BL object itt het fetchen van een ervan? In een aparte collections of manage klasse? En saven zijn dan eerst de DAO objecten, of heb je DAO achtige operaties op je BL objecten zitten? (bijv. door een gedeelte van je BL objecten te laten inheriten van DAO objecten)?

offtopic:
Ben ik nog te begrijpen zo of is bovenstaande tekst te warrig?

[bodiam]

Infinitive schreef op 13 september 2004 @ 15:33:
[...]

Welk object heeft dan op dat moment de verantwoordelijkheid voor het aanmaken van nieuwe BL objecten en DAOs?

Bijv. geef je de Primary Key mee aan je BL object zodat hij de corresponderende DAO(s) kan laden vanuit de DAL? Maar hoe maak je dan een nieuw BL object itt het fetchen van een ervan? In een aparte collections of manage klasse? En saven zijn dan eerst de DAO objecten, of heb je DAO achtige operaties op je BL objecten zitten? (bijv. door een gedeelte van je BL objecten te laten inheriten van DAO objecten)?

Ik begrijp niet helemaal wat je bedoelt (je gebruikt ook wel erg veel afkortingen ), maar volgens mij kom ik steeds hetzelfde tegen. Ik had laatst het 'geweldige' idee om mijn constructor te gebruiken voor het construeren van objecten. Jaja.
Echter, ik had daarbij de beperking opgelegd dat ik pas het object kon maken als ik aan de minimale eisen van het object voldeed. In het geval van een product was dit de Naam, de Prijs, en een ID uit de Database. Dat laatste is of enorm stom, of ik heb het niet goed uitgewerkt, want het werkt enorm rot. Al mijn gegevens meeslepen naar een 'save klasse' is echt een gedoe, en de beste manier die ik had verzonnen was gewoon een HashMapje met daarin alle gegeven. In feite dus gewoon een object als 'Product', maar dan in de vorm van een Map. Niet echt handig dus.

Ik ben er nu weer vanaf gestapt, en maak ze gewoon weer met een lege constructor. De database ID zit nog wel steeds in het object (wat ik op zich ook wel irritant vind, maar waar ik nog geen goed alternatief voor gevonden heb).

Mijn business logic zou ik graag buiten mijn objecten stoppen. Dus niet in het object, maar ook niet in de actions. Eigenlijk wou ik graag Jess gaan gebruiken daarvoor, maar ik weet ook nog niet waar die regels dan vastgelegd dienen te worden.

[whoami]

Alarmnummer schreef op 13 september 2004 @ 13:06:
Maar plaats je de business logica bij het gedrag van een domein object in

Dit zou ik zo doen ja.

of maak je een apart BusinessLogic/Service achtig object aan, waarmee je domein objecten reduceert tot records.

Waarom zou je dat doen? Wordt alles dan niet te complex?

[Infinitive]

whoami schreef op 13 september 2004 @ 17:03:
Waarom zou je dat doen? Wordt alles dan niet te complex?

Volgens mij wordt het dan simpeler
Je domein objecten zijn dan gewoon gegenereerde data access objects (DAOs). Verder heb je wat "management objecten" die d.m.v. de DAL deze objecten laden, saven, etc en daarnaast ook de logica bevatten. Je hoeft dan geen aparte BL objecten te hebben en dat scheelt weer wat werk. Het nadeel is dan alleen dat je niet echt een mooi object geörienteerd model hebt: het is dan meer het idee van "functies" en "structures" in een taaltje als C (waarbij je dan een klein beetje OO gebruikt).

[zneek]

Infinitive schreef op 13 september 2004 @ 15:33:
[...]

Welk object heeft dan op dat moment de verantwoordelijkheid voor het aanmaken van nieuwe BL objecten en DAOs?

Bijv. geef je de Primary Key mee aan je BL object zodat hij de corresponderende DAO(s) kan laden vanuit de DAL? Maar hoe maak je dan een nieuw BL object itt het fetchen van een ervan? In een aparte collections of manage klasse? En saven zijn dan eerst de DAO objecten, of heb je DAO achtige operaties op je BL objecten zitten? (bijv. door een gedeelte van je BL objecten te laten inheriten van DAO objecten)?

offtopic:
Ben ik nog te begrijpen zo of is bovenstaande tekst te warrig?

Ik werk meestal vanuit een MVC structuur. Mijn controller ontvangt aan de ene kant requests van de gebruiker, en praat aan de andere kant met BL objecten
Op dit moment maken de BLs nog zelf DAOs aan naar behoefte en voeren eventueel op te slaan entity objecten aan die DAO. Terwijl ik dit nu schrijf realiseer ik me dat dat misschien niet de meest cleane oplossing is, immers mijn BL objecten zijn redelijk hard afhankelijk van de DAO objecten.

Maar, ik kan wel lekker snel functies bouwen. Definieer een command, de bijbehorende controller en view (jsp). Vervolgens is het een kwestie van BL functies aanmaken die de command nodig heeft.

De controller is in mijn opzet de lijm, de BL objecten zijn een toolbox met functies, de DAOs zijn hulpclasses om find, save en delete opdrachten voor een entity uit te voeren. De entity class is niet meer dan een record object.

[edit] het werken met objecten met een PK heb ik ge-abstraheerd. Ik heb een HandleStringConverter die van een string weergave naar een Object en terug kan vertalen. Middels BeanUtils (en een entityconverter die gebruik maakt van de HandleString functies) kan ik elk object op elk willekeurig object in stellen bij het ontvangen van de request. De term PK, of het PK veld kom ik nergens tegen.

[ Voor 12% gewijzigd door zneek op 13-09-2004 19:16 ]

[djengizz]

Ik ben zeker voorstander van het scheiden van de business logica en de entiteit.
Belangrijkste redenen
• Entiteiten zijn de grootste kandidaat voor transport over netwerk. Het scheiden van de logica reduceert de overhead (buiten het feit dat ze vaak serializible moeten zijn en dit is een dure operatie).
• Vaak gaat BL over meerdere entiteiten (zie ook de reactie van zneek).
• Het voorkomt 'wildgroei-achtige' spagetti: Het zal veel moeilijker worden wijzigingen en functionele uitbreiding te realiseren door het tightly coupled zijn van logica en entiteit.

Het volgende plaatje is een mooi pattern wat illustreerd waar mijn voorkeur ligt.
De Entity Beans zijn uiteraard niet noodzakelijk. Wel is een vorm van BusinessSession i.c.m. een BusinessEntity een goed idee die natuurlijk ook op een andere manier is te implementeren.


http://java.sun.com/bluep...terns/TransferObject.html

[Alarmnummer]

Heb je verder uberhaubt nog validatie logica in je business objecten? Null checks.. range checks ..

[Macros]

djengizz schreef op 13 september 2004 @ 21:07:
• Entiteiten zijn de grootste kandidaat voor transport over netwerk. Het scheiden van de logica reduceert de overhead (buiten het feit dat ze vaak serializible moeten zijn en dit is een dure operatie).

Logica/code wordt niet verstuurd over een netwerk hoor. Ik kan niet zien hoe dat overhead zou geven.

[zneek]

Alarmnummer schreef op 13 september 2004 @ 21:19:
Heb je verder uberhaubt nog validatie logica in je business objecten? Null checks.. range checks ..

Validatie lijkt me ( voor een groot deel ) taak van de BL. Validatie is namelijk voor een deel context afhankelijk. Stel je een HRM applicatie voor. Een werknemer mag zijn eigen logingegevens aanpassen, maar niet zijn vrije uren saldo. In de werknemer functie "gegevens wijzigen" wordt op een andere manier gevalideerd dan in de PenO manager functie "werknemer wijzigen".

Ik kies er meestal voor om veld validatie in de entity te doen. Controleren of een postcode een postcode is, controleren of een datum wel geldig is. Maar bij een periode kies ik er voor om in de BL af te dwingen dat start niet na eind mag liggen. Alles wat je van 1 enkel veld kunt valideren op basis van alleen dat veld doe ik in de entity, samengestelde eisen in de BL.

[ Voor 6% gewijzigd door zneek op 13-09-2004 23:36 ]

[zneek]

Macros schreef op 13 september 2004 @ 22:25:
[...]

Logica/code wordt niet verstuurd over een netwerk hoor. Ik kan niet zien hoe dat overhead zou geven.

Wel als je je entity objecten en bl objecten in 1 verpakking stopt. Dan gaat bij alle transport ook een kopie van de logica over de lijn, niet alleen van de data.

[djengizz]

Macros schreef op 13 september 2004 @ 22:25:
[...]
Logica/code wordt niet verstuurd over een netwerk hoor. Ik kan niet zien hoe dat overhead zou geven.

Tuurlijk wel, elk messaging protocol (CORBA, RMI, Http) zal remote objecten moeten creeëren of invoken. Zaken als: class references, object references, method references, and method arguments zullen altijd over 'het lijntje' moeten. Dit is ook de reden dat ze vaak serializable (inpakbaar voor het netwerk) zijn.
Ander voorbeeld:

Java:

Object requestObject = new SomeRequestType();
URL servlet = new URL(serverUrl);
HttpURLConnection con = (HttpURLConnection)servlet.openConnection();
ObjectOutputStream out = new ObjectOutputStream(con.getOutputStream());
out.writeObject(requestObject);

[ Voor 4% gewijzigd door djengizz op 13-09-2004 23:49 ]

[ACM]

zneek schreef op 13 september 2004 @ 23:36:
Wel als je je entity objecten en bl objecten in 1 verpakking stopt. Dan gaat bij alle transport ook een kopie van de logica over de lijn, niet alleen van de data.

Waarom moet je bij Java dan zowel aan de server als aan de client-kant van de call dezelfde klassen hebben? In principe hoeft alleen datgene overgestuurd te worden, dat overblijft als je een object serialized en de logica is daar geen onderdeel van.
Er zijn natuurlijk ook varianten waarbij een kant specifieke klassen niet kent en verzoekt een kopie van de klasse op te sturen, maar dat is niet dé enige manier waarop de boel werkt. Bij RMI en ObjectStream's bijvoorbeeld standaard niet, voor zover ik weet.

djengizz schreef op 13 september 2004 @ 23:49:
Dit is ook de reden dat ze vaak serializable (inpakbaar voor het netwerk) zijn.
Ander voorbeeld:

Java:

Object requestObject = new SomeRequestType();
URL servlet = new URL(serverUrl);
HttpURLConnection con = (HttpURLConnection)servlet.openConnection();
ObjectOutputStream out = new ObjectOutputStream(con.getOutputStream());
out.writeObject(requestObject);

Heb je dat voor de grap ook es serieus bekeken wat daarbij overgestuurd wordt? In principe is het nergens voor nodig om de beschrijving van een klasse mee te sturen en dat wordt dan zeer zeker ook niet bij een serialized object meeverpakt. Uiteraard zijn er allerlei services die als ze een object van een onbekende klasse tegenkomen in een request, ze bijvoorbeeld verzoeken die klasse op te sturen, maar dat is niet het enige of zelfs standaard gedrag zoals ik al zei.

Helaas verteld Sun niet wat de Serializable-interface precies doet in de javadoc, maar dit stukje ervan is wel een goede indicator:

quote: http://java.sun.com/j2se/...java/io/Serializable.html

The readObject method is responsible for reading from the stream and restoring the classes fields. It may call in.defaultReadObject to invoke the default mechanism for restoring the object's non-static and non-transient fields.

[ Voor 14% gewijzigd door ACM op 14-09-2004 08:48 ]

[whoami]

IMO wordt logica idd niet overgestuurd.
In .NET remoting bv heb je aan de client kant een 'proxy' object die verantwoordelijk is voor het aanroepen van de juiste method op de server.

Ik geloof dat het type wel meegestuurd wordt, zodat er een object van dat type aan de andere kant van de lijn kan gemaakt worden.

Als je in .NET trouwens een class 'Serializable' maakt door het implementeren van de ISerializable interface, dan ga je in de GetObjectData method gaan aangeven wat er geserialiseerd moet worden; je gaat daar aangeven welke member-variabelen er moeten geserialiseerd worden, en je gaat er geen methods gaan serializen.

[ Voor 35% gewijzigd door whoami op 14-09-2004 08:52 ]

[Alarmnummer]

Ok... laten we niet offtopic gaan en gewoon blijven bij het 'waar plaats ik de logica' verhaal. Verneuk maar iemand anders zijn topic.

Verder heb ik het ook totaal niet gehad over serialzen van objecten en het laatste wat je verder wilt is dat je je objecten gaat serializen over de lijn. Daar heb je Data Transfer Objecten (DTO`s) voor.

Dus... niet meer discusieeren over serializen.

[ Voor 51% gewijzigd door Alarmnummer op 14-09-2004 09:16 ]

[kasper_vk]

Het antwoord is, denk ik, puur een kwestie van goed OO-denken.

En dan bedoel ik: de domein-klassen heb je tijdens het ontwerpen een bepaalde verantwoordelijkheid opgelegd, waaraan je je tijdens het verdere ontwerp strikt dient te houden.
Is de verantwoordelijkheid van je domein-klassen niets anders dan het representeren van een record uit de database, dan hebben methoden die op meerdere record werken dus *niets* te zoeken in één van je domein-klassen.
Je maakt dan dus aparte Service / BL / Action - klassen die de verantwoordelijk voor een bepaalde recordoverschrijdende bewerking krijgen.

Wanneer je gebruiktmaakt van een database, je via je DAL records raadtpleegd en die wilt gaan gebruiken in je BL, heb je een object nodig om die data over te dragen van DAL naar BL: iets als record objecten, ValueObjects o.i.d.
Omdat deze objecten worden aangemaakt in je DAL, mag er (m.i.) dus geen BL in die klassen zitten. Maak je een strikte scheiding tussen je DAL en je BL, dan ontkom je er dus niet aan om je BL te scheiden van de record-representatie.

Volgens mij wordt het wel anders wanneer je een (geheel transparante) persistente opslag van je objecten hebt, zoals een object-database, EJB of een krachtige O/R mapper. In dat geval kun je als ontwikkelaar overwegen om meer verantwoording bij de domein-klassen te leggen, omdat je als ontwikkelaar geen (zichtbare) DAL meer hebt en dus ook de scheiding DAL/BL mag vergeten.

[Eelke Spaak]

Ik vind het fijn om voor mijn Data Access Objects iets simpels als sql2java te gebruiken; dit genereert zeer simpele entity objecten die weinig meer zijn dan records uit de database.

Volgens mij wordt het allemaal een beetje onoverzichtelijk als ik ook range-checking e.d. in de gegenereerde source code ga zetten, dus probeer ik dat zoveel mogelijk in een aparte laag te zetten.