Λέγοντας "persistent objects" εννοούμε κάθε αντικείμενο τα περιεχόμενα του οποίου δεν χάνονται με το τέλος της εφαρμογής, αλλά μπορούν να αποθηκευτούν και να επανακτηθούν οταν ζητηθούν.

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

Τα stored procedures και η SQL που αναφέρεις δεν έχουν (άμεσα) να κάνουν με τα αντικείμενα αυτά, αλλά μπορούν να χρησιμοποιηθούν για την αποθηκεύση και την ανάκτηση τους απο την βάση δεδομένων.

Δημοσθένης Στελλάκης

Μμμ, λίγο ασαφής ερώτηση μια και ο όρος "Persistent Objects" έχει πολλές πρακτικές ερμηνίες, ιδιαίτερα αν ρωτήσεις developers που ασχολούνται με διαφορετικές γλώσσες.  Θα υποθέσω ότι αναφέρεσαι στην γενικότερη πρακτική να αγνοείς την βάση δεδομένων, να κρατάς τα αντικείμενα στην μνήμη (γιατί όπως λένε "ram is getting cheaper") και να τα κάνεις persist σε flat files/xml/simple databases σε τακτά χρονικά διαστήματα.

Παρόλο που έχει κάποια πλεονεκτήματα σε performance, εγώ δεν το χρησιμοποιούσα ποτέ, ιδιαίτερα σε κάποια mission critical εφαρμογή γιατί πάσχω από οξεία παράνοια/φοβία απώλειας δεδομένων :), επίσης δε έχω συναισθηματικούς δεσμούς με τον SQL Server. Επιπρόσθετα, αν δεν είσαι 100% σίγουρος για το uptime του συστήματος που κάνει host τα bussiness objects (multi-failover architectures, robust clusters, κλπ) θα ήταν καλό να επενδύσεις σε καλά αθλητικά παπούτσια γιατί θα πέσει πολύ κυνήγι από πελάτες μια μαύρη μέρα. Μπορείς να ρίξεις μια ματιά εδώ για το φιλοσοφικό του πράγματος (είναι για Java το συγκεκριμένο, αλλά τα σχόλια είναι γενικά εύστοχα και platform independent)

Τώρα για λιγότερο extreme πρακτικές, π.χ. χρήση διαφόρων ORM mappers, κλπ, η απάντηση πάλι δεν είναι εύκολη. Προφανώς και κάποια καλά εργαλεία μπορεί να αυξήσουν σημαντικά την παραγωγικότητα και τον κατεκερματισμό της εργασίας σε ένα μεγάλο project (αν και εδώ που τα λέμε στο ελλάντα σπάνια βλέπει κανείς μεγάλα project teams) αλλά πρέπει να έχε προηγηθεί πολύ καλή ανάλυση και design (δεν ξέρω για σας, εγώ δεν την παλεύω ιδιαίτερα με ασκήσεις επί χάρτου :) ) για να μην έχεις θέμα με πιθανό schema evolution, requirements changes, κλπ. Εν γέννει, μια και η δημοσίευση είναι στα "πρώτα βήματα" θα πρότεινα να βεβαιωθείς ότι είσαι απόλυτα εξοικιωμένος με τις "παραδοσιακές" τεχνικές ανάπτυξης και ότι μπορείς να κάνεις μια καλή εκτίμηση του χρόνου και της ποιότητας με την οποία θα ανταπεξέλθεις σε ένα project και μετά να ασχοληθείς με την πολυτέλεια του να βελτιώσεις την απόδοση του τελικού αποτελέσματος, να κάνεις refactor, κλπ.

Εκτός βέβαια αν είσαι από τους λίγους εκλεκτούς και τυχερούς που πληρόνονται αδρά για μια θέση R&D :)

Παναγιώτης Καναβός:

Μόνο R&D δεν είναι αυτά τα θέματα, άσχετο αν πολλοί τώρα τα ανακαλύπτουν, μαζί με το Object Oriented Programming και το Multi-Threading. Άσε που το LINQ to SQL είναι ευκολότερο στη χρήση από τα datasets ...

Δεν ξέρω αν έχω αστοχία αντίληψης στο συγκεκριμένο, αλλά από αυτά που βλέπω στην αγορά όσον αφορά της εταιρείες που γράφουν εφαρμογές η πλειοψηφία μάλλον σε φάση διερεύνησης  των συγκεκριμένων θεμάτων είναι.  Μακάρι να κάνω λάθος, αυτό μπορεί να σημαίνει ότι είμαστε πιο μπροστά σαν σύνολο απ'ότι νομίζω :)

Μία πολύ γρήγορη απάντηση, γιατί δεν προλαβαίνω τώρα. Το impedance mismatch αφορά τη δυσκολία επικοινωνίας object-oriented εφαρμογών και βάσεων. Τα ORMs αντιμετωπίζουν αυτό το πρόβλημα, δεν το δημιουργούν. Αντίθετα, η χρήση stored procedures/dynamic sql για να φορτώσεις δεδομένα και μετά να δημιουργήσεις τα αντικείμενα είναι το πρόβλημα. Κάπως θα πρέπει τα δεδομένα που σου έρχονται σε μορφή πίνακα να τα κάνεις αντικείμενα και μάλιστα ολόκληρη ιεραρχία αντικειμένων. Για παράδειγμα, πως θα φορτώσεις από μία βάση τα υλικά που χρειάζονται για να φτιάξεις .... ένα αυτοκίνητο, όταν το καθένα από αυτά μπορεί να περιέχει επιμέρους υλικά κλπ, σε μεγάλο βάθος?

Θα επανέλθω όμως αργότερα

Επειδή βιάζομαι, θα το πω λίγο απότομα. Ούτε μπροστά ούτε πίσω βρίσκονται οι εταιρείες, σε φάση σοκ και άρνησης βρίσκονται. Σοκ ίδιο με αυτό που έπαθαν όταν από VB6 αναγκάστηκαν να μεταβούν σε .ΝΕΤ. Κάποιες εταιρείες θα έχουν πολύ εύκολη μετάβαση, αν έχουν καν, καθώς χρησιμοποιούν ORMs και παρόμοιες τεχνικές εδώ και χρόνια. Άλλες θα το παλέψουν λέγοντας "μα τί κάνουν τα ORM που δεν κάνουν τα datasets" μέχρι να μείνουν τελευταίες απ' όλους και να μην μπορούν ούτε να ακολουθήσουν τους ανταγωνιστές τους, ούτε να βρουν καλούς προγραμματιστές πρόθυμους να δουλέψουν σε "αρχαίες" τεχνολογίες.

Η ίδια κατάσταση που εμφανίστηκε με τη μετάβαση σε .NET θα εμφανιστεί και τώρα. Υπάρχουν ακόμα εταιρείες οι οποίες έχουν μείνει στη VB6 και δεν μπορούν να περάσουν πλέον σε .NET επειδή δεν μπορούν να βρουν πρόθυμους προγραμματιστές.

Όταν βρω χρόνο, θα γράψω και γιατί από Java μεριά χρησιμοποιούν ORMs και JBoss για να φτιάξουν highly scalable συστήματα ενώ από MS μεριά ακόμα συζητάμε αν θα βγάλουμε τον κώδικα από τις φόρμες. Για την ώρα, το Is Microsoft Serious? του Ted Neward εξηγεί τους ιστορικούς λόγους από τη σκοπιά κάποιου ο οποίος έχει δουλέψει και έχει γράψει βιβλία και για τις δύο πλευρές (Effective Enterprise Java, C# in a Nutshell) , όπως π.χ. ότι παρότι η Microsoft είχε application servers από τον καιρό των Windows NT 4.0, έπρεπε να φτάσουμε στο .ΝΕΤ για να αποκτήσει και μία εύκολη γλώσσα.

1. Σχεδίαση ενός feature ή αλλαγή κάποιου υφιστάμενου
   
2. Ανάπτυξη των αντικειμένων που θα χρειαστούν στη βάση για να κρατάνε τα δεδομένα (πίνακες, sequences)
3. Ανάπτυξη των αντικειμένων που θα χρειαστούν στη βάση για business logic (procedures, triggers, packages, views κλπ)
4. Ανάπτυξη του κώδικα σε Delphi που να χρησιμοποιεί τα αντικείμενα αυτά
5. Κλήση των αντικειμένων αυτών από το UI κλπ
6. Αν θέλουμε να αλλάξουμε κάτι μετά GOTO 1

1
2
3
4
5
6
 

using (UnitOfWork uow = new UnitOfWork())
{
  Customer myCustomer = new Customer(uow);
  myCustomer.Name = "Μήτσος";
  uow.CommitChanges();
}