.NET Framework

Απ: Persistence

lounerios — Fri, 01 Feb 2008 02:00:22 GMT

Καλησπέρα, άρχισα να χρησιμοποιώ το nhibernate στο project. Παρατήρησα όμως κάποια προβλήματα σχετικά με την ταχύτητα.
Καταρχήν, η βάση που χρησιμοποιώ είναι mysql και ενώ με το ADO.Net χρειάζονται 0,3 δευτερόλεπτα για να φορτώσω 10000 messages, με το nhibernate ο χρόνος φόρτωσης είναι 2,3 δευτερόλεπτα.

Είναι φυσιολογική αυτή η τόσο μεγάλη διαφορά στην ταχύτητα ή εγώ κάνω κάτι λάθος;

Ευχαριστώ.

Απ: Persistence

lounerios — Tue, 29 Jan 2008 19:17:18 GMT

Καλημέρα και πάλι.

Την τελευταία εβδομάδα διαβάζω για το Nhibernate αλλά δεν μπορώ να βρω λύση στο πρόβλημα με την αντίστοιχιση διαφορετικών πινάκων στην ίδια κλάση. Από ότι διάβασα το hibernate3 για java υποστηρίζει το entity-name, αλλά δεν υπάρχει ακόμα υλοποίηση για το Nhibernate.

Απ: Persistence

Παναγιώτης Καναβός — Tue, 22 Jan 2008 19:53:59 GMT

Οι δύο πίνακες σου αντιστοιχούν χονδρικά σε δύο διαφορετικές οντότητες οι οποίες έχουν τον ίδιο βασικό τύπο, το μήνυμα. Αυτό μπορείς να το αναπαραστίσεις και στο NHibernate ορίζοντας ότι υπάρχει μία σχέση inheritance από μία κοινή κλάση π.χ. Message. Έτσι θα έχεις τρεις κλάσεις: Την κοινή abstract Message και τις IncomingMessage και OutgoingMessage. Στο mapping file θα ορίσεις ότι ισχύει το table-per-class (δεν προλαβαίνω να δω πως γράφεται).

Στο τέλος θα μπορείς να τραβήξεις όλα τα μηνύματα μέσω της Message ή μόνο τα εισερχόμενα ή εξερχόμενα μέσω των αντίστοιχων κλάσεων.

Απ: Persistence

lounerios — Tue, 22 Jan 2008 19:12:42 GMT

Καλημέρα, έφτιαξα ένα μικρό παράδειγμα με το nhibernate και διαπίστωσα ότι δουλεύει μια χαρά.

Βασικά τώρα θα ήθελα να σας ρωτήσω αν μπορώ να αντιστοιχίσω δύο πίνακες σε μια κλάση. Στην βάση χρησιμοποιούμε δύο πίνακες, ένα πίνακα όπου αποθηκεύουμε τα εισερχόμενα e-mails και έναν για τα εξερχόμενα. Οι δύο πίνακες διαφέρουν σε 3 columns και θα ήθελα να τους αντιστοιχίσω στην ίδια κλάση Message.
Είναι δυνατόν αυτό;

Απ: Persistence

Παναγιώτης Καναβός — Thu, 17 Jan 2008 06:09:53 GMT

Όχι, εννοώ τον O/R Designer που εμφανίζεται όταν δημιουργείς ένα νέο αρχείο τύπου LINQ to SQL classes. Σε αυτό μπορείς να τραβήξεις πίνακες και stored procedures από το Data Source view. Ο designer δημιουργεί αυτόματα κλάσεις για κάθε πίνακα και δημιουργεί properties για τα one-to-many relations που εντοπίζει μέσω των foreign keys. Δυστυχώς, δεν υποστηρίζει many-to-many relations, αν και μπορεί κάποιος να τα υλοποιήσει κατά κάποιο τρόπο να τα φτιάξει προσθέτωντας methods ή properties τα οποία επιστρέφουν π.χ. τα Mailboxes που αντιστοιχούν σε ένα χρήστη:

partial class User
{
public IQueryable<Mailbox> Mailboxes
{
    get
    {
      EmailsDataContext ctx = ContextManager.Context;
      return from u in ctx.UserMailboxes
            join m in ctx.Mailboxes on u.MailboxID equals m.MailboxID
            select m;
    }
}
}

Απ: Persistence

KelMan — Thu, 17 Jan 2008 04:07:35 GMT

Μμμμ... Έχει το LINQ to SQL γραφικό designer; Παναγιώτη, μήπως εννοείς το Entity Framework με το LINQ to Entities;

Απ: Persistence

lounerios — Thu, 17 Jan 2008 03:56:22 GMT

Κυρίως, το mapping με απασχολεί περισσότερο αυτή την στιγμή .
Οσον αφορά τις υπόλοιπες δυνατότητες που προσφέρει, από ότι είδα θέλουν αρκετό χρόνο και διάβασμα!!!

Απ: Persistence

Παναγιώτης Καναβός — Thu, 17 Jan 2008 03:53:25 GMT

Καλύτερα να ρίξεις πρώτα μία ματιά στο LINQ to SQL καθώς είναι πιο εύκολο και περιλαμβάνει γραφικό designer. Τα queries που περιγράφεις πάντως, μπορούν να γίνουν εύκολα από όποιο ORM έχει τη δική του γλώσσα για queries. Εδώ που τα λέμε, αυτό το είδος εφαρμογής είναι μία καλή περίπτωση για να δεις και να συγκρίνεις τα διάφορα ORM μεταξύ τους.

Απ: Persistence

KelMan — Thu, 17 Jan 2008 03:38:13 GMT

Ναι, απλά όπως ανέφερε και ο Παναγιώτης, μην απογοητευτείς από το learning curve που έχει.

Απ: Persistence

lounerios — Thu, 17 Jan 2008 02:40:05 GMT

Θα δοκιμάσω ένα απλό παράδειγμα με το nHibernate. Απ' όσες open source βιβλιοθήκες είδα αυτή μου φάνηκε με τις περισσότερες προοπτικές.

Απ: Persistence

KelMan — Thu, 17 Jan 2008 01:56:33 GMT

Τα περισσότερα ORMs έρχονται μαζί με παραδείγματα, casts, how-to's, κλπ. Θα μπορούσατε - ως τμήμα του research - να αφιερώσετε λίγο χρόνο και να κάνετε ένα μικρό παράδειγμα ώστε να δείτε πως ακριβώς χρησιμοποιούνται, σε τι βολεύουν, σε τι δεν βολεύουν, τι προβλήματα λύνουν και εν τέλει πόσο μπορούν να σας βοηθήσουν. Χρειάζεται τουλάχιστον μια μικρή αίσθηση του τι μπορεί να κάνει ένα τέτοιο εργαλείο για να μπορείτε να πάρετε απόφαση πέρα από αυτά που σας λέμε εδώ. Προσωπικά, δεν βλέπω γιατί να μην μπορεί να ανταποκριθεί ένα ORM σε αυτές τις απαιτήσεις που περιγράφεις.

Απ: Persistence

lounerios — Thu, 17 Jan 2008 00:40:03 GMT

Αφορά μια εφαρμογή για διαχείριση e-mail. Κάτι σαν το outlook, μόνο που όλα τα δεδομένα (e-mails,contacts,κτλ) βρίσκονται σε μια βάση και δίνει την δυνατότητα στους
χρήστες να παρακολουθούν κοινούς λογαριασμούς.

Όσον αφορά τα δυναμικά queries, θα σου δώσω δύο παραδείγματα:
έχουμε ένα κεντρικό πίνακα messages, όπου περιέχοντα όλα τα e-mails και έναν άλλο πίνακα msg_read_status, όπου περιέχονται
πληροφορίες για το ποιος χρήστης βλέπει ποιο e-mail. Όταν ένας χρήστης βλέπει το inbox του πρέπει να κάνουμε joins τους δύο πίνακες.

Πιο πολύπλοκο γίνεται όταν ο χρήστης κάνει αναζήτηση στα e-mails επεδή σε κάποιες περιπτώσεις όταν ψάνχει στο body χρησιμοποιούμε
full text search και σε άλλες το like. Η βάση έχει περίπου 2,000,000 emails...

Αυτά
Ελπίζω να μην σε κούρασα.

Απ: Persistence

Παναγιώτης Καναβός — Wed, 16 Jan 2008 23:54:28 GMT

10 αντικείμενα αλλά πολλά δυναμικά queries? Κάπως περίεργο ακούγεται αυτό. Τα queries δηλαδή επιστρέφουν τα ίδια δέκα αντικείμενα αλλά από πολλούς διαφορετικούς πίνακες? Π.χ. το αντικείμενο Product μπορεί τώρα να έρχεται από τον πίνακα MyProduct, μετά από τον YourProduct? Θα πρέπει να εξηγήσεις καλύτερα τί θέλεις να κάνεις γιατί μπορεί αυτό που θέλεις να γίνεται εύκολα αλλά να μην το έχεις καταλάβει.

Μήπως οι πίνακες αυτοί αντιστοιχούν σε κάποια σχέση inheritance? Αυτό καλύπτεται από τα ORMs. Οι τρεις βασικοί τρόποι αποθήκευσης inheritance σε τέτοιες περιπτώσεις είναι ή ένας πίνακας για όλη την ιεραρχία (καλό αν υπάρχουν μικρές διαφορές και λίγοι τύποι), ένας πίνακας ανά κλάση με όλα τα πεδία της κλάσης, inherited και μη (π.χ. άλλος πίνακας για το ParentProduct, άλλος για το ChildProduct), ή ένας ανά κλάση αλλά μόνο με τα πεδία της κάθε κλάσης. Στην τελευταία περίπτωση, για να φορτώσεις ένα ChildProduct πρέπει να κάνεις join τους πίνακες ChildProduct και ParentProduct.
Όλα αυτά μπορούν να αποτυπωθούν π.χ. στο mapping file του NHibernate ώστε όταν φορτώνεις ChildProduct κλάσεις το ORM να φτιάχνει αυτόματα τα κατάλληλα queries κι έτσι εσύ να μην καταλαβαίνεις ποτέ αν τα δεδομένα ήρθαν από ένα ή περισσότερους πίνακες.

Τέλος, έχε υπόψη ότι πολλά ORM έχουν τη δική τους γλώσσα για queries οπότε μπορούν να εκτελέσουν ό,τι query θέλεις. Μπορείς επίσης να ορίσεις (τουλάχιστον στο NHibernate) ότι τα αποτελέσματα ενός query (hard-coded στο mapping file) ή stored procedure θα αντιστοιχούν στη X κλάση. Κάτι παρόμοιο κάνει και το LINQ.

Απ: Persistence

lounerios — Wed, 16 Jan 2008 22:56:36 GMT

Ευχαριστώ για τις πληροφορίες.

Δυστυχώς τα δυναμικά queries σε ορισμένες περιπτώσεις δεν μπορούμε να τα αποφύγουμε, βέβαια με αυτά που αναφέρεις ίσως μέσω του orm και κάποιου κώδικα από την δική μας πλευρά να γίνεται.

Έχω και κάποιες επιφυλάξεις αν πρέπει να χρησιμοποιήσουμε orm, γιατί η εφαρμογή μας έχει περίπου 10 αντικείμενα.

Ίσως θα μπορούσαμε να φτιάξουμε ένα δικό μας layer για την φόρτωση, αποθήκευση των δεδομένων.

Απ: Persistence

Παναγιώτης Καναβός — Wed, 16 Jan 2008 22:05:46 GMT

Και σήμερα με ρώταγε κι άλλος για το ίδιο πράγμα! Μιλημένοι είσαστε? (Τί κρατάει ο Ναπολέων?). Αν ψάξεις για ORM στο DNZ θα δεις κάποιες συζητήσεις, ενώ υπάρχει και το How to Select an Object Relational Mapping το οποίο είναι λίγο παλιό. Από τότε όλα σχεδόν τα εμπορικά ORM έχουν φτάσει στο ίδιο περίπου σημείο.

Γιατί δυναμικά queries? Ως τώρα έχω δεί τρεις λόγους για τη χρήση δυναμικών queries. Ad-hoc search, προσπάθεια δημιουργίας Data Layer με χαρακτηριστικά ORM, ή δημιουργία business entity framework. Το ad-hoc search δεν το γλυτώνεις. Αν όμως χρησιμοποιήσεις κάποιο ORM, τα δυναμικά queries και τα joins θα τα κάνει το ίδιο το ORM. Η δημιουργία business framework είναι μία άλλη μεγάλη συζήτηση, την οποία δεν θέλω να ξεκινήσω αν δεν σε ενδιαφέρε. (Όπως θα καταλάβεις σε λίγο, όταν αρχίσω δύσκολα σταματάω).

Ένα αντικείμενο μπορεί άνετα να γίνει mapped σε πολλούς πίνακες. Σε περίπτωση μάλιστα που θέλεις να αποθηκεύσεις κλάσεις οι οποίες έχουν σχέσης inheritance ένα αντικείμενο μπορεί να καταλήξει να αποθηκεύεται σε 1, 2 ή περισσότερους πίνακες ανάλογα με το μοντέλο inheritance mapping που επιλέγεις. Το mapping αυτό συνήθως το ορίζεις σε ένα mapping αρχείο αν και υπάρχουν μεγάλες διαφορές από εργαλείο σε εργαλείο. Το LINQ to SQL για παράδειγμα έχει γραφικό περιβάλλον, το NHibernate έχει xml mapping file, αν και υπάρχουν μερικοί designers, άλλα εργαλεία έχουν τα δικά τους.

Το τί ORM θα επιλέξεις εξαρτάται από το τί θέλεις να το κάνεις. Για παράδειγμα, το Subsonic κάνει πολύ εύκολα mapping και generation των data objects, δεν τα πάει όμως καθόλου καλά με το concurrency. Είναι καλό για internet/intranet web sites, κακό για web applications και transactional συστήματα. Το NHibernate θέλει χρόνο να το μάθεις αλλά έχει υποστήριξη για inheritance mapping, concurrency της επιλογής σου, lifecycle management (πότε και για πόση ώρα θα είναι ανοικτά τα connections?), lazy ή eager loading (φορτώνω όλα τα αντικείμενα ενός collection με τη μία ή όταν τα ζητήσω?), long transactions (transactions τα οποία έχουν ισχύ ακόμα και όταν κλείσει το connection από το οποίο τραβήχτηκαν τα δεδομένα). Είναι πολύ καλό για transactional συστήματα και web applications. Έχει πολύ μεγάλη αποδοχή από τους C# developers οπότε μπορείς να βρεις σχεδόν πάντα κάποιον που θα έχει δουλέψει στα σενάρια που σε ενδιαφέρουν.

O άλλος σημαντικός παράγοντας είναι ποιοί θα το χρησιμοποιήσουν? Όποιος δεν έχει δουλέψει με transactional συστήματα ή δεν καταλαβαίνει από patterns θα δυσκολευτεί να καταλάβει το πως δουλεύουν τα πιο προχωρημένα ORMs και το γιατί. Άς πάρουμε για παράδειγμα το eager/lazy loading. Αν έχεις μία κλάση με 50 πεδία τα οποία είναι επίσης κλάσεις, θέλεις να φορτωθούν όλα όταν φορτώσεις την parent κλάση, ή μόνο όταν το ζητήσεις? Αν φορτωθούν όλα, θα δημιουργηθεί ένα SQL statement σεντόνι, θα κτυπήσεις όμως τη βάση μόνο μία φορά. Αυτό είναι το eager loading. Αν τα φορτώσεις μόνο όταν τα θέλεις, θα εκτελούνται συχνά πολλά μικρά statements. Αυτό είναι το lazy loading. Αν δουλεύεις σε ένα collection από αντικείμενα, το lazy loading μπορεί να σου κοστίσει πολύ ακριβά σε round trips. Το eager loading μπορεί να φορτώνει πολλά πράγματα με τη μία αλλά να έχει καλύτερο scalability από το lazy loading - ή όχι.
Για transactional και scalable συστήματα θα πρέπει να χρησιμοποιήσεις κάποιο προχωρημένο ORM όπως το NHibernate ή το ADO.NET Entity Framework και να το δώσεις σε senior προγραμματιστές. Για web sites και RAD development μπορείς να δώσεις ένα απλούστερο όπως το Subsonic ακόμα και σε junior προγραμματιστές.

Το LINQ to SQL μπορεί να παίξει και στις δύο κατηγορίες, αν και για τα transactional συστήματα θα πρέπει να γράψεις επιπλέον κώδικα για το concurrency, lifecycle κλπ που θέλεις. Το καλό με το LINQ είναι ότι μπορείς να το χρησιμοποιήσεις παράλληλα με όποια άλλη λύση ORM επιλέξεις, π.χ. για να φορτώνεις lookup δεδομένα ή να φορτώσεις αντικείμενα τα οποία δεν χρειάζονται τις επιπλέον υπηρεσίες που δίνει ένα ORM.