[J2EE] Gebruik van Value Objects

[FendtVario]

intro
Bij het besturderen van de het J2EE pattern Value Objects (VO) viel het me op dat er veel dubbel werk in zit. Zo hebben de business classes (BC) en bijbehoordende value objects dezelfde getters en setters. Er is een mogelijkheid om de business class te laten overerven van het value object maar die vlieger gaat weer niet op als het business object voor verschillende clients verschillende vo's maakt. Maar ik heb een ander probleem bij VO's. Wat doe je met de controle?

Een voorbeeldje
Hieronder heb ik een simpele klasse gemaakt met en een bijbehoordend VO.

Java:

public class BusinessClassTest {
  private int lowest;
  private int highest;

  public BusinessClassTestVO createBCTVO() {
    return (new BusinessClassTestVO(lowest, higest));
  }

  public int getLowest() {
    return lowest;
  }

  public void setLowest(int arg0) {
    if (arg0 > lowest) {
      throw new Exception.create(“arg0 is niet het laagste”);
    }
    lowest = arg0;
  }

  //hetzelfde voor highest

}

public class BusinessClassTestVO implements Serializable {
  private int lowest;
  private int highest;

  public BusinessClassTestVO() {
  }

  public BusinessClassTestVO(int low, int high) {
    lowest = low;
    highest = high;
  }

  //VO getter en setters zonder controle
}

In de BC wordt de data gecontroleerd, in de VO niet. Op een gegeven moment komt de VO weer bij de BC terug, moet je dan de data gaan controleren? Dit betekent dus dat de create van de BC de eigen setter methodes moet gebruiken? In het voorbeeld van Sun staat bijvoorbeeld de procedure mergeKlasse(VO updated) die direct naar de private variabelen schrijft.

Het lijkt mij handiger om alleen voor de weergave VO's te gebruiken omdat er dan toch niets wijzigd. Op moment dat er data gewijzigd wordt wil je dit zo vroeg mogelijk controleren.

wat is nu de vraag?
Op dit moment werk ik met Servlets waarin direct de business objects gemaakt worden en de gegevens in gegooid worden. Deze klasse wordt dan ook aan de Data Access Objects (DAO's) (ander pattern) doorgegeven. Ik gok dat het op dit punt beter is om een VO mee te geven. DAO's horen waarschijnlijk ook VO's terug te geven ipv complete business classes. Wanner moet ik nu werkelijk VO's gebruiken en wanneer vindt de controle op gegevens plaats? Heeft iemand nog een leuk voorbeeld buiten die van Sun?

[small]Sorry voor de vele afkortingen, hoop dat het nog duidelijk is[/small

[zneek]

Waarom gebruik je uberhaupt VOs? Ik gebruik mijn Hibernate Entity objecten ook als VOs. Zijn toch al platte objecten. In een eerder project werkten we met EJB CMP, en dan heb je geen keuze. Elke set actie op een EJB is dan ook persistent. Maar met Hibernate kies ik er zelf voor om een lading set acties wel of niet te saven, eventueel na een validatie. Sterker nog, door gebruik te maken van Transactions hoef ik me daar niet eens druk om te maken. Als 1 van de zoveel set acties op eventueel meerdere objecten fout gaat wordt de hele transaction terug gedraaid.

Wat voegt het VO pattern toe in jouw situatie? Waarom kun je de BC objecten niet direct gebruiken?

[FendtVario]

Hibernate ken ik nog niet, daar ben ik nog niet aan toegekomen. De VO's waren een gedachte onderdeel van optimalisatie. VO is kleiner en kan daardoor sneller over een netwerk (nu nog niet het geval maar wie weet wat de toekomst brengt). Daarnaast heb ik het idee dat ik beter een VO aan een RequestDispatches kan meegeven dan een BC. Waarom? De BC bevat veel functies die je toch niet gebruikt bij de weergave.

Andere reden om de vraag te stellen is nieuwsgierigheid, omdat een VO niets doet aan controle was ik benieuwd waar je de controle dan _wel_ moet uitvoeren.

[ronaldmathies]

Ik gebruik Value Objecten en daarnaast een validatie classe. Deze validatie classe wordt binnen of de Facade gebruikt of op het allerlaagste niveau op het niveau van de entity bean.

Voorbeeld:

code:

    public static void validateCode(String code) throws ValidationException {
        ArrayList errorCodes = new ArrayList(3);
        boolean throwException = false;
        if (code == null) {
            errorCodes.add("error.code.not.null");
            throwException = true;
        } else {
            if (code.length() == 0) {
                errorCodes.add("error.code.length.min");
                throwException = true;
            }
            if (code.length() > 8) {
                errorCodes.add("error.code.length.max");
                throwException = true;
            }
            if (!code.equals(code.toUpperCase())) {
                errorCodes.add("error.code.uppercase");
                throwException = true;
            }
        }
        if (throwException) {
            throw  new ValidationException("Code is not valid.", errorCodes);
        }
    }

[zneek]

FendtVario schreef op woensdag 26 januari 2005 @ 20:42:
Hibernate ken ik nog niet, daar ben ik nog niet aan toegekomen. De VO's waren een gedachte onderdeel van optimalisatie. VO is kleiner en kan daardoor sneller over een netwerk (nu nog niet het geval maar wie weet wat de toekomst brengt). Daarnaast heb ik het idee dat ik beter een VO aan een RequestDispatches kan meegeven dan een BC. Waarom? De BC bevat veel functies die je toch niet gebruikt bij de weergave.

Andere reden om de vraag te stellen is nieuwsgierigheid, omdat een VO niets doet aan controle was ik benieuwd waar je de controle dan _wel_ moet uitvoeren.

Kijk, als ze over het netwerk gaan is het wel een verstandige keuze. Maar dan nog, waarom zit je BL in je Entity object? Ik splits dit altijd op in 2 of meer objecten, 1 entity en 1 of meerdere business logic objecten/services.

[Alarmnummer]

FendtVario schreef op woensdag 26 januari 2005 @ 20:14:
intro
Bij het besturderen van de het J2EE pattern Value Objects (VO)

Hou er rekening mee dat er 2 definities zijn voor value object:
-martin fowler en cornuiten: een value object is een object zonder identiteit. Een persoon object heeft bv een identiteit en ik kan niet zomaar een andere instantie neerzetten. Geld daarentegen is een value object: object zonder identitieit. Voor het systeem maakt het niet uit welk euro object ik heb.
-veel andere pipo`s: Data Transfer Object. Dat is een object zoals jij het beschrijft. Het doel van een DTO`s is om netwerk communicatie efficienter te maken door de data te verzamelen in dat in 1 schop het internet over te schoppen.. zodat het aan de andere kant eventueel bewerkt kan worden en later weer terug gestuurd. Jij kan deze dto`s dan weer uitlezen en terug koppelen aan je eigen objecten.

viel het me op dat er veel dubbel werk in zit. Zo hebben de business classes (BC) en bijbehoordende value objects dezelfde getters en setters.

Een beetje afhankelijk van de technieken die je gebruikt ben je niet altijd DTO`s nodig. Wij werken veel met webapplicaties zonder al te veel remoting geneuzel met andere java platformen en ik heb eigelijk ook nog geen behoefte gehad aan DTO`s.

Er is een mogelijkheid om de business class te laten overerven van het value object maar die vlieger gaat weer niet op als het business object voor verschillende clients verschillende vo's maakt. Maar ik heb een ander probleem bij VO's. Wat doe je met de controle?

We zijn nu net bezig om de validatie functionaliteit volledig te onkoppelen van de datadrager. Dit gaan we doen door de validatorfunctionaliteit in en apart object te plaatsen en dat te binden aan onze entiteitsobjecten. Hierdoor kan iedereen dus gebruik maken van de validator... we kunnen het zelfs meegeven aan andere objecten (in ons geval zal zometeen mbv een stevige portie reflectie in de weblayer veel onzinnig geneuzel ermee worden opgelost).

In het geval van DTO`s zou je het daar ook aan kunnen binden en overschoppen naar de andere kant. Op die manier hoef je niet bang te zijn dat je duplicate code hebt... Dit zie je trouwens ook wel terug bij andere systemen zoals Struts. Alleen jammer dat deze Validator volledig gekoppeld is aan het framework en je systeem dus ook... erg slechte zaak imho.

Op dit moment werk ik met Servlets waarin direct de business objects gemaakt worden en de gegevens in gegooid worden.

Tot zover zie ik nog geen behoefte voor DTO`s.

Deze klasse wordt dan ook aan de Data Access Objects (DAO's) (ander pattern) doorgegeven. Ik gok dat het op dit punt beter is om een VO mee te geven.

Waarom??

DAO's horen waarschijnlijk ook VO's terug te geven ipv complete business classes.

Waarom? Het doel van die DTO`s is om eenvoudig data over te kunnen pompen ipv dat een client en server apps de hele tijd met elkaar aan het lullen zijn.. mag ik van jou een voornaam? jan... mag ik van jou een achternaam? bakker.. mag ik van jou een leeftijd? 2. Dit soort kletspartijen brengt enorme overhead met zich mee.. dus vandaar.. prop alles in een soort afspiegeling van het echte object.. schop die de lijn over.. en haal die later weer op. (indien nodig)

Wanner moet ik nu werkelijk VO's gebruiken en wanneer vindt de controle op gegevens plaats? Heeft iemand nog een leuk voorbeeld buiten die van Sun?

Ik werk zelf niet met EJB en ik geloof dat daar de behoefte aan DTO`s veel hoger is. Maar in de applicaties die ik schrijf ben ik ze dus nog niet tegengekomen. Ga dus goed na of je het uberhaubt nodig bent

Sorry voor de vele afkortingen, hoop dat het nog duidelijk is

Je hebt zeker nog niet veel met XML gedaan

Onthoud:
Don`t pay for what you don`t use...

[ Voor 17% gewijzigd door Alarmnummer op 27-01-2005 05:42 ]

[FendtVario]

@rolandmathies: De techniek heb ik ook gebruikt, aparte klassen voor validatie. Daarbij werk ik ongeveer op dezelfde manier als jij laat zien, een bericht dat alle fouten terug geeft, alleen doe ik dat niet met een exeption.

@alarmnummer: wat ik opmaak uit je verhaal is dat het gebruik van VO's in meer overhead geeft dan oplossingen. Waarom ik VO's aan DAO's wil geven? VO's zijn kleiner en wat moet een DAO met alle procedures, ik dacht hoe kleiner hoe beter. Maar het maken van de VO's is nu meer werk dan dat het zal opleveren.

Met XML ben ik nog niet verder gekomen dan een paar XSL transforms en wat gerommel met XM in Delphi. Niet echt diepgaand allemaal.

[Kwistnix]

Een VO object zoals jij dat gebruik heeft wel wat weg van een Memento object.
Tenminste ik vind de overeenkomsten wel treffend, immers beide doen ze niet veel meer dan de state van een object onthouden als ik het goed begrijp (al zijn de toepassingsgebieden wel verschillend natuurlijk).

[ Voor 42% gewijzigd door Kwistnix op 27-01-2005 12:29 ]

[whoami]

Een VO (of DTO) komt eigenlijk alleen maar van pas als je , zoals Alarmnummer al verteld heeft, je gegevens via remoting oid moet versturen.

Als je dit niet doet, dan zie ik niet in waarom je ze zou willen gebruiken.

[ Voor 11% gewijzigd door whoami op 27-01-2005 11:56 ]

[bloody]

Mijn ervaringen met dto's wil ik nog wel even kwijt:
Voordelen:

• Geen geneuzel met ingewikkelde domein modellen, maar gewoon snel op simpele objecten ontwikkelen (aan de presentatie kan dan).
• Klein, dus beter geschikt voor remote overdracht.

Nadelen:

• Concurrency: Hoe doe je dit?? Omdat je dto los gekoppeld is van je domein heb je daar geen binding/state meer mee. Je moet dus dto's een versie/id attribuut geven oid, waarmee je een ConcurrentModificationException kunt gooien.
• Synchronisatie: Hoe hou je de dto bomen en domein/business bomen gelijk? Als je dus een veldje 1 je business toevoegd, moet je die dus ook in je dto toevoegen.
• De overall complexiteit neemt toe, omdat je ahw een extra laag toevoegd.

Doe er je voordeel mee.

[zneek]

bloody schreef op zaterdag 29 januari 2005 @ 11:44:
Mijn ervaringen met dto's wil ik nog wel even kwijt:
Voordelen:

• Geen geneuzel met ingewikkelde domein modellen, maar gewoon snel op simpele objecten ontwikkelen (aan de presentatie kan dan).
• Klein, dus beter geschikt voor remote overdracht.

Nadelen:

• Concurrency: Hoe doe je dit?? Omdat je dto los gekoppeld is van je domein heb je daar geen binding/state meer mee. Je moet dus dto's een versie/id attribuut geven oid, waarmee je een ConcurrentModificationException kunt gooien.
• Synchronisatie: Hoe hou je de dto bomen en domein/business bomen gelijk? Als je dus een veldje 1 je business toevoegd, moet je die dus ook in je dto toevoegen.
• De overall complexiteit neemt toe, omdat je ahw een extra laag toevoegd.

Doe er je voordeel mee.

Lijkt me een redelijk kloppend lijstje. Lijkt me ook dat de situatie van TS niet vraagt om zo'n complexe oplossing. Een van de belangrijke minpunten is de complexiteit die toeneemt, en zoals Alarmnummer al zei: dont pay for what you dont use. Waarom zaken complexer maken dan nodig. Overigens is het argument dat je DAO geen compleet domein object hoeft te hebben met alle methodes erin natuurlijk zinsloos. Het domein object bestaat al, anders zou je er geen VO van kunnen maken, en vervolgens geef je die VO aan je DAO: waar zit het voordeel tov direct je domein object aan de DAO passen?

[FendtVario]

Dank voor de reacties, zoals ik al zei is het een experiment projectje om mezelf j2ee machtig te maken. Het gebruik van VO's in de huidige opzet met servlets is inderdaad overkill. VO's dus alleen gebruiken als de applicatie remote draait en controle op de input kan via een losse Validator klasse.