Klassen & Associaties, translatie naar database

[Foeijonghaai]

Als ik een simpel klassediagram teken en op basis daarvan Java-code schrijf, krijg ik andere code dan wanneer ik een ORM of persistentie gebruik.

Voorbeeld:

levert de code

Java:

import java.util.Collection;
import java.util.ArrayList;

public class Auteur {
   private String naam;
   private Collection<Boek> geschreven;

   public Auteur(){
      naam = new String();
      geschreven = new ArrayList<Boek>();
   }

   public String getNaam(){
      return naam;
   }

   public void setNaam(String n){
      naam = n;
   }

   public Collection<Boek> getGeschreven(){
      return geschreven;
   }

   public void addGeschreven(Boek b){
      geschreven.add(b);
   }

   public void removeGeschreven(Boek b){
      geschreven.remove(b);
   }
}

En voor Boek iets wat hier op lijkt, maar dan voor Boek ;-). Let met name op 'getGeschreven()', waarmee ik alle Boeken voor die Auteur kan verkrijgen.

Als ik dit in de database ga opslaan, heb ik een koppeltabel nodig, want het is een many-to-many relatie.


Als ik de ORM/persistentie-tool (bijv. Cayenne of Propel) de code hiervoor laat genereren (nadat ik zelf de database heb opgezet heb), heb ik een extra klasse Auteurschap. En de klasse Boek kent geen Auteur meer, maar heeft een lijst van Auteurschap. Idem voor Boek.

Dit is onhandig. Auteurschap heeft verder geen attributen en ik wil geen extra klasse.

Bij one-to-many gebeurt is geen koppeltabel nodig en onstaat er ook geen extra klasse en gebeurt dit niet.

Ik kan er om heen werken door bijvoorbeeld in Auteur.java een methode te maken genaamd getGeschreven() die itereert over de Auteurschap-objecten (voor die Auteur) en de bijbehorende boeken verzameld in een lijst en deze retourneert en iets soortgelijks voor Boek.java.

Maar dan doe ik het laatste deel van de methode (maken van lijst met boeken) in software. Het lijkt me dat de database dat sneller kan.

Wat gaat hier mis en/of wat is de beste aanpak ?

• Is dit gewoon een gevolg van dat het relationele model zich niet zonder meer laat vertalen naar een klassendiagram en vice versa?
• Is het in het algemeen moeilijk voor ORM/persistentie-tools om te bepalen of iets een koppeltabel is puur om many-to-many mogelijk te maken?

In de literatuur mis ik met name de koppeling tussen implementatie en ontwerp. Menig boek gaat of alleen UML of alleen over database design. Bij mijn opleiding idem.

Het enige boek wat in de buurt komt is het boek van Gertjan Laan (UML en java in de praktijk), maar dat eindigt (helaas) nadat persistentie en de vertaling van klassendiagram naar databasediagram behandeld is.Hoe dit in de praktijk werkt ontbreekt.

Kunnen jullie nog literatuur aanbevelen?

[CurlyMo]

Foeijonghaai schreef op dinsdag 05 juni 2012 @ 11:08:
Maar dan doe ik het laatste deel van de methode (maken van lijst met boeken) in software. Het lijkt me dat de database dat sneller kan.

Dat is volgens mij een van de weinige mogelijkheden die je hebt.Een andere mogelijkheid is het maken van views die de gegevens van de boeken in een Array inleest. Via triggers en stored procedures zou deze vervolgens weer bij een insert of update kunnen verdelen over je onderliggende tabellen. Zo creëer je twee lagen in je database. De opslag laag bestaande uit al je tabellen waarin je data wordt opgeslagen en een presentatie laag die de gegevens uit je tabellen samenvoegt tot makkelijkere uit te lezen tabellen (views) aan je software.

[Kwistnix]

Het is voor een O/R mapper zeker niet per definitie noodzakelijk om een klasse te genereren, welke niets meer is dan een afspiegeling van de koppeltabel. Hibernate en EclipseLink hebben een dergelijke oplossing bijvoorbeeld niet nodig, dus het is geen impliciete gevolg van de mismatch tussen het OO-model en het relationele model.

Edit: Voorbeelden van hoe je een n:m relatie kan mappen voor een JPA provider (Hibernate / EclipseLink / whatever...) kan je in de API docs vinden van de ManyToMany annotatie.

[ Voor 28% gewijzigd door Kwistnix op 05-06-2012 12:52 ]

[Foeijonghaai]

FallenAngel666 schreef op dinsdag 05 juni 2012 @ 12:44:
Het is voor een O/R mapper zeker niet per definitie noodzakelijk om een klasse te genereren, welke niets meer is dan een afspiegeling van de koppeltabel. Hibernate en EclipseLink hebben een dergelijke oplossing bijvoorbeeld niet nodig, dus het is geen impliciete gevolg van de mismatch tussen het OO-model en het relationele model.

Edit: Voorbeelden van hoe je een n:m relatie kan mappen voor een JPA provider (Hibernate / EclipseLink / whatever...) kan je in de API docs vinden van de ManyToMany annotatie.

Ik heb 'even' een test gemaakt met OpenJPA en ook met Hibernate/JPA. Daarmee krijg ik het voor elkaar dat er geen klasse voor de koppeltabel gemaakt hoeft te worden.

Maar dan moet ik de simpele code (de business objects) wel zelf schrijven.Voordeel van Cayenne en Propel is dat ik ze kan gebruiken om code te genereren van al bestaande databases. Misschien is dit ook mogelijk met Hibernate, maar dat moet ik nog uitzoeken.

[Kwistnix]

Tsja, dat is een manier, maar dat leidt wel tot een anemic domain model van twijfelachtige OO kwaliteit.
Ik ben er zelf eerlijk gezegd geen voorstander van, maar het kan best een valide keuze zijn natuurlijk; bijvoorbeeld dus in een project waar je al met legacy databases zit.
Er zijn overigens wel tools die een O/R model kunnen transformeren naar een OO model en daar Java code en bijbehorende Hibernate mappings uit kunnen genereren; PowerDesigner kan dat volgens mij.
Overigens biedt Jboss ook Hibernate Tools aan, waarmee je op basis van hibernate mappings Java POJO's en DDL statements kan genereren, maar da's in jouw situatie ook niet echt handig.

[Foeijonghaai]

FallenAngel666 schreef op donderdag 07 juni 2012 @ 13:38:
Tsja, dat is een manier, maar dat leidt wel tot een anemic domain model van twijfelachtige OO kwaliteit.
Ik ben er zelf eerlijk gezegd geen voorstander van, maar het kan best een valide keuze zijn natuurlijk; bijvoorbeeld dus in een project waar je al met legacy databases zit.
Er zijn overigens wel tools die een O/R model kunnen transformeren naar een OO model en daar Java code en bijbehorende Hibernate mappings uit kunnen genereren; PowerDesigner kan dat volgens mij.
Overigens biedt Jboss ook Hibernate Tools aan, waarmee je op basis van hibernate mappings Java POJO's en DDL statements kan genereren, maar da's in jouw situatie ook niet echt handig.

Bedankt voor je input.

Ik heb de Hibernate Plugin voor Netbeans geinstalleerd en deze de database laten 'reverse-engineeren' (volgens http://netbeans.org/kb/docs/web/hibernate-webapp.html) . Ook deze tool genereert geen extra klasse voor Auteurschap. Boek.java en Auteur.java krijgen allebei lokaal een HashSet voor de referenties naar de andere objecten.

[Janoz]

Het punt is dat een tool niet zomaar automatisch af kan leiden of iets enkel een koppeltabel is, of dat het ook daadwerkelijk een functie heeft in het domein van je applicatie. Zolang je het perse automagisch wilt doen zul je altijd tegen dit soort dingen aan lopen. Het beste blijft gewoon om te beginnen met een automatische export en deze vervolgens handmatig gaan finetunen (een dergelijke 'koppel class' is er natuurlijk redelijk simpel tussenuit te refactoren)