Introduzione

Negli articoli precedenti abbiamo affrontato gli aspetti teorici della modellazione UML, identificando le entità che partecipano all'applicazione per la gestione di un apiario. Abbiamo definito il metamodello concettuale, analizzato le relazioni tra le entità e preparato il terreno per la fase successiva: il design dello strato di persistenza. In questo articolo vedremo come tradurre il modello concettuale in classi persistenti utilizzando le specifiche JPA (Java Persistence API) con le annotazioni di EJB3. Passeremo dal metamodello alla creazione delle tabelle del database e delle classi entity che ne rappresentano il mapping object-relational, affrontando le diverse tipologie di relazioni e le strategie di generazione delle chiavi primarie.

@GeneratedValue(strategy = GenerationType.AUTO)
private Integer id;

@Column(name = location)
private String location;

@Column(name = name)
private String name;

@Column(name = description)
private String description;

@OneToMany(mappedBy = apiary)
private Collection<Family> familyCollection;

public Apiary() {
}

public Apiary(Integer id) {
this.id = id;
}
// segue elenco dei metodi get/set
}

Per il momento tralasciamo la query in EJBQL delle quali parleremo in seguito e ci concentreremo invece su due aspetti interessanti per quello che concerne la definizione delle regole di persistenza: da un lato si può notare come la chiave primaria (campo id) sia mappata nel database tramite la strategia di generazione automatica (in questo caso si usa un contatore progressivo); questa modalità si ottiene con la annotazione

@GeneratedValue(strategy = GenerationType.AUTO)

L'altro fattore interessante è dato dall'annotazione

@OneToMany(mappedBy = apiary)
private Collection<Family> familyCollection;

che consente da un lato di mantenere la relazione a livello di oggetti (infatti la classe Apiary contiene un riferimento a una collezione di oggetti Family) ma che contemporaneamente si preoccupa di specificare che la relazione verrà mantenuta dall'altra parte della relazione, ossia che la persistenza verrà salvata sul database in virtù di quanto specificato nell'attributo apiary della classe Family. Per maggior chiarezza di seguito è riportato il codice della classe corrispondente:

@Entity
@Table(name = family)
@NamedQueries({@NamedQuery(name = Family.findById, query = SELECT f FROM Family f WHERE f.id = :id),
@NamedQuery(name = Family.findByPosition, query = SELECT f FROM Family f
WHERE f.position = :position)})
public class Family implements Serializable {
private static final long serialVersionUID = 1L;

@Id
@Column(name = id, nullable = false)
@GeneratedValue(strategy = GenerationType.AUTO)
private Integer id;

// la posizione della arnia entro cui la famiglia è contenuta
@Column(name = position)
private Integer position;

// campo che contiene le note per la famiglia
@Lob
@Column(name = notes)
private String notes;

// relazione con l'apiario al quale la famiglia appartiene
@JoinColumn(name = apiary_id, referencedColumnName = id)
@ManyToOne
private Apiary apiary;

// campo di relazione con la regina che vive in questa famiglia
@JoinColumn(name = queen_id, referencedColumnName = id)
@OneToOne
private Queen queen;

// campo di relazione con il report
@JoinColumn(name = report_id, referencedColumnName = id)
@ManyToOne
private Report report;

public Family() {
}

public Family(Apiary a) {
this.apiary = a;
}

// seguono i metodi get/set
}

Anche in questo caso si può notare la definizione della strategia di assegnazione della chiave, ma è più importante la annotazione che permette di specificare la relazione: in questo caso la classe Family si prende la responsabilità di salvare la relazione con l'entità Apiary. La caratteristica della relazione di composizione fra la famiglia e l'apiario si può tradurre nel fatto che una famiglia non può vivere al di fuori di un apiario: il costruttore di Family quindi ha fra i suoi parametri anche un riferimento all'oggetto Apiary. Il costruttore di default (che di fatto viola tale indicazione del modello) è necessario per rispetto delle specifiche JavaBeans.

Conclusioni

Per questo mese ci fermiamo qui: proseguiremo il mese prossimo parlando delle relazioni che sono rimaste in sospeso affrontando alcune casistiche piuttosto importanti. Successivamente affronteremo la definizione dello strato di business logic e la creazione dello strato client.

Riferimenti e Bibliografia

  • [EJB-a] EJB 3.0

[http://java.sun.com/products/ejbhttp://java.sun.com/products/ejb

  • [EJB-b] G. Puliti, Enterprise Java Beans 3.0, MokaByte 111, ottobre 2006

http://www2.mokabyte.it/cms/article.run?articleId=3VL-HPK-X3O-RI27f00000130520983_55d21c14

  • [FOW] Martin Fowler, Kendall Scott, UML Distilled, Addison-Wesley Professional
  • [LVT] Luca Vetti Tagliati, UML e ingegneria del software, Tecniche Nuove
  • [LAR] Craig Larman, UML and Design Patterns, Prentice Hall PTR
  • [A2] Apicoltura 2000 - portale di apicoltura

http://www.apicoltura2000.it/

  • [MDI] Mieli d'Italia: sito della Unione Nazionale Associazioni Apicoltori Italiani

http://www.mieliditalia.it