Friday, April 27, 2007

Domain,DTO objects και EJB 3.0 Entity Beans

Στην τελευταία ημερίδα του jhug , αλλά και κατ ιδίαν ρώτησα τον Patrick Linskey για το ποια ειναι η καλύτερη τακτικη στο να πάρουμε data από την βάση και να τα δείξουμε σε μία σελίδα.Είναι καλό να παίρνουμε όπως είναι τα entity beans μας τα οποία ουσιαστικά είναι τα Domain/ DTO object μας από την εποχή του Hibernate 2.x ή αφού γεμίσουμε τα entity beans μέσα απο το DAO layer να έχουμε μια έξτρα ομάδα κλάσεων καθαρά Data Transfer objects τα οποία θα ταξιδεύουν στο web layer!

Ειπε ότι δεν υπάρχει direct λύση στο ερώτημα,

α)πολλές φορές με την χρήση πια EJB 3.0 και entity beans θα αναγκαστείς να φέρεις στο προσκήνιο ένα xtra layer απο DTO object τα οποία συνήθως θα είναι πιο light weight σε ποσότητα πληροφορίας από το κλασικό entity bean το οποίο είναι αντικατοπτρισμός ενός πίνακα στην βάση δεδομένων. Ναι μεν λοιπόν θα έχεις πολλαπλές κλάσεις οι οποίες θα ορίζουν ουσιαστικά duplicated πληροφορία πχ to DTO θα έχει την μισή πληροφορία από το Entity bean αλλα θα έχεις καταφέρει να χωρίσεις σε ακόμα μεγαλύτερο βαθμό το persistence layer με το web layer και φυσικά τον σύνδεσμο τους..ο οποίος δεν είναι άλλος από την πληροφορία που θέλουμε να δείξουμε στον χρήστη!

β)άλλες φορές (τις πιο πολλές είπε) η απλότητα και η ευκολία του να ταξιδεύει
το entity bean EJB3.0 στο web layer ειναι πραγματικά βολική.Εξάλλου πρέπει να σκεφτούμε οτι ουσιαστικα το EJb3.0 και το νέο Entity Bean δημιουργήθηκε γι'αυτο το σκοπό - μεσα απο την εμπειρία των Domain Objects άλλων ORM. Επίσης μην ξεχνάμε οτι ουσιαστικα πολλά νεα web framework δουλευουν με αυτη την λογικη. Δες το Seam, πειρε τα ευέλικτα πια Entity beans και τα δένει με Java Server Faces web components...πολυ έυστοχα ο δημιουργός του Gavin King , τα ονομάζει web-beans μιας και αυτό είναι!

Μόλις τελειώσα ένα set απο functionality σε prototype επίπεδο για την εφαρμογή που ετοιμάζουμε. Επέλεξα να χρησιμοποιήσω Struts στο web layer και EJB 3.o σε ολες του τις μορφές στο business - persistence layer. Δεν εισήγαγα νέο layer με DTO τα Entity, οι εντυπώσεις μου ειναι άριστες. Είναι αρκετα βολικό να ξέρεις οτι ειναι η ιδια κλάση που ουσιαστικα κάνει το mapping με τον πίνακα, η ιδια που τις τραβάς attributes για να τα δειξεις σε κάποια σελίδα.

Το μόνο που θα ήθελα στο Struts αυτη την στιγμή ειναι να υποστηρίξει IoC (με annotations) όπως πχ γίνεται στο Seam , για να εισάγω πιο εύκολα τα Entity beans μου σε αυτό, η ακόμα και τα Session Beans σε Actions κτλ κτλ. Πάντως για την ώρα ...η τεχνολογία works as expected...οκ για την ώρα δεν με πειράζει που το JPA εχει σε κάποια σημεία limit όσο αναφορά το functionality σε σχέση με το Pure Hibernate 3.0 approach! Μπορώ να περιμένω - αλλιώς θα ξεκινήσω να κάνω import hibernate πακέτα - κάτι που έτσι και αλλιώς σε advanced features θα χρειαστεί να το κάνω!

2 comments:

  1. Συμβαίνει να δουλεύω σε κάτι με πολύ παρόμοια αρχιτεκτονική με αυτό που περιγράφεις. Πως έχεις αντιμετωπίσει το θέμα των detached entities; Εννοώ ότι όταν το entity έχει φτάσει πια στο jsp για να εμφανιστούν κάποια properties του, το transaction έχει τελειώσει, είσαι έξω από το persistence context και κάποια lazy properties είναι uninitialized. Προσωπικά, ανάλογα με την κάθε περίπτωση, είτε φροντίζω να είναι eagerly loaded καποια πεδία που θα χρειαστώ είτε τα ζητάω ξεχωριστά. Καμία από τις δύο λύσεις δεν μου αρέσει απόλυτα γι'αυτό ρωτάω να δω πως το αντιμετωπίζουν και άλλοι. Ευχαριστώ.

    ReplyDelete
  2. Γεια σου αγαπητέ! Ακολουθώ την συμβουλή του - 'reduce the database overhead' δηλαδή τα πολλαπλά πάρε δώσε. Συνηθως προσπαθω να έχω το web layer ηδη έτοιμο με την έννοια ότι φιάχνω σελίδες που πχ ξέρω οτι θα θέλω να έχω έτοιμο το ParentEntityBean και χρειάζεται να δείξω σχεδόν πάντα και εκείνο το lazy collection. Άρα γενικα για μένα Collections ειναι ολα Lazy, και παίζω πάντα με FETCH JOIN για να σπάσω το lazyness τους! Οσο αναφορά απλά property προτιμώ κάποιο βασικό set απο proerties έτσι και αλλιώς να τα φορτώνει απο default (το κάνει ηδη - anyway).

    Θα υπάρχουν και περιπτώσεις που το eager θα βολέψει με την έννοια ότι η σελίδα ειναι έτσι φιαγμένη ή η λογική της που ειναι σίγουρο ότι θα χρειαστεί τελικά εκεί το eager property ο χρήστης...οπότε και να το κλικάρει μια φορά και να το φέρει οκ δεν χάλασε ο κόσμος. Αν όμως ειναι να το φέρνει 9 στις 10 τοτε καλύτερα αγαπητέ αν δεν ειναι μεγάλο άστο να στο φέρνει με την μια..ή αλλιώ Lazy και JOIN στο Select που κάνεις απο κάτων. Εδω βοηθάει και το DAO layer σαν pattern μιας και μπορείς να εμπλουτίσεις το MyEntiyDAOBean με πολλές και διαφορετικές μεθόδους που συνήθως θα σπάνε το lazyness.

    Δυστηχώ εχω μπλέξει με ένα αρκετά μεγάλο σχήμα - και αναγκαστηκλα δεν μπορώ να μεταφέρω στο web layer τέραστιους γράφους με συνδεδεμένα οbject...

    lazy for me please!

    ελπιζω να σε κάλυψα..στον βαθμό που μπόρεσα!

    ReplyDelete