"Ενημερωνόμουν" τελευταία, για τις εξελίξεις στο .NET 3.0, ιδιέταιρα στο πασίγνωστο πλέον Language Integrated Query, όπου πλέον έχει το συντακτικό για να περιγράψεις queries στη γλώσσα της προτίμησής σου ... εντάξει, το υπεραπλουστεύω λίγο τώρα, αλλά for the sake of argument ...

Παράλληλα / ταυτόχρονα, κοιτούσα το Entity Framework, κάτι σαν OR Mapping (ακριβώς αυτό είναι εδώ που τα λέμε, αλλά ... integrated ). Ο designer φανταστείτε είναι σα να φτιάχνεις typed datasets, μόνο που πλέον έχεις τη δυνατότητα να συνδυάζεις πίνακες της βάσης στα "datatables" σου, δημιουργώντας ακριβώς τα entities που χρειάζεσαι, σα να φτιάχνεις ένα νέο schema πάνω απο τη βάση, όπως σε βολεύει  εσένα για τη συγκεκριμένη περίσταση - αυτό μπορεί να αποδειχθεί σωτήριο όταν η δουλειά σου είναι στο product development, όπου πρέπει το βασικό σου framework να είναι όσο το δυνατόν πιο "ανοιχτό" σε variations του αρχικού σχεδιασμού :)

Τέλος πάντων, τα δύο αυτά εργαλεία συνδυάζονται καταπληκτικά μεταξύ τους, μετατρέποντας τον C# "linq" κώδικά σας πρώτα σε queries πάνω στα objects - τα instances των entities τα οποία είχατε καθορίσει. Στη συνέχεια, το entity framework θα κάνει map αυτά τα queries σε κλήσεις στη βάση, με θεωρητικά τον optimal τρόπο.

Όταν πλέον έχεις τη δυνατότητα να κάνεις queries natively μέσα στη γλώσσα πάνω σε properties των objects, είναι πλέον μάταιο να υπάρχει το interface του DataSet, το rows and columns view. Τα entities που καθορίζεις στο entity framework, γίνονται code generated assemblies. Οπότε, έχεις την ευχέριεα να καθορίσεις πάνω κάτω, οποιοδήποτε class design μπορεί να χρειάζεσαι πάνω απο τα δεδομένα data.  Για παράδειγμα,  μια βάση με  μετεωρολογικά δεδομένα ( καλά το'γραψα;;; ) μπορεί να τραφοδοτήσει applications με φοβερά διαφορετικό αντικείμενο. Είναι λοιπόν πολύ βολικό να έχεις ένα τρόπο να καθορίσεις ένα class design "πάνω" απο τα δεδομένα αυτά.

Όλοι λοιπόν, είναι μες στη χαρά για αυτόν τον πραγματικά πολύ όμορφο τρόπο να σβήσει η Microsoft τον ανταγωνισμό όσον αφορά το O/R Mapping σε .NET. Κι εγώ μαζί ! Αν δεν έβγαινε αυτό, ίσως πολλοί άνθρωποι να μην έβλεπαν ποτέ O/R Mapper σε χρήση. Ούτε κι εγώ, τουλάχιστον όχι σε production κώδικα.

Το point μου όμως είναι, ότι ίσως το linq - μόνο του, χωρίς το entity framework - δεν είναι καλή επιλογή για data access όσον αφορά  RDBMS's, όχι όσο είναι φοβερή επιλογή για in-memory querying! Φανταστείτε το, όλα αυτά τα object data structures που έχετε τόσον καιρό δημιουργήσει, ξαφνικά γίνονται queryable, in-memory, και γράφοντας C# κώδικα.

Φ α ν τ α σ τ ι κ ό ! ! !

Τέλος πάντων, αυτό είναι το point ... linq μόνο για in-memory querying και προσεχτικά με τη βάση, ή πάμε αβέρτα κι οποιον πάρει ο χάρος;;;

---

Angel
O:]

Γιατί έχω εκείνη την εντύπωση ότι το LINQ και το ADO.NET vNext (Entity Framework) είναι στο Visual Studio Orcas timeframe, κάπου ένα εξάμηνο μετά το release του Windows Longhorn Server και όχι με το .NET Framework v3.0;

Από ότι θυμάμαι θα είναι μια έκδοση της σειράς v3.x, αλλά όχι v3.0...

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Δεν σε εμποδίζει τίποτε να χρησιμοποιήσεις OR Mapping σε production κώδικα. Υπάρχουν πολλοί OR Mappers για .NET, ξεκινώντας από open source όπως το NHibernate μέχρι commercial όπως το LLBLGEN Pro και το Ideablade.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Και φυσικά όλοι οι .Net Ο/R mappers θα μπορούν να υλοποιήσουν το LINQ στα συστήματά τους, κάνοντας map στις υπάρχουσες OQL υλοποιήσεις τους.

---

Palladinos Nick
Software Engineer
-----------------------
The limits of my language mean the limits of my world. (Ludwig Wittgenstein)

Φυσικά δε σε εμποδίζει κανείς να χρησιμοποιήσεις O/R Mappers σε production κώδικα. Εκτός βέβαια, αν το υπάρχον code base είναι αχανές, και αλλαγή σε O/R Mapping μπορεί να σημαίνει ένα 6-μηνό total rewrite, με αμφίβολα αποτελέσματα - προσωπικά σε αυτή την κατάσταση βρίσκω τον εαυτό μου στη δουλειά - φαντάζομαι και πολλοί άλλοι. Εξ' ού και το "τουλάχιστον όχι σε production" σχόλιό μου.

Υποστηρίζω οτι πολύς κόσμος θα δεί με το vNext για πρώτη φορά O/R Mapping, γιατί απλώς θα είναι available με ένα πολύ φιλικό τρόπο out-of-the-box. Πoλύ πιο φιλικό απο το NHibernate ( του οποίου ήμουν πάντα μεγάλος οπαδός, ακόμη κι απο τα Java days μου ), LLBGen κτλ κτλ κτλ. Προς το παρόν με άλλα λόγια, αν κάνουμε ένα γκάλοπ στο dotNetZone για το πόσοι όντως χρησιμοποιούν O/R Mappers, πόσο ποσοστό λέτε να βγάλουμε; Μικρό θα υποθέσω. Αν κάνουμε τοι ίδιο γκάλοπ μετά παο 1 χρόνο, όταν το vNext θα είναι πλέον commonplace, τί διαφορές θα περιμένατε σε αυτό το ποσοστό; Μεγάλες θα έλεγα εγώ ! Αυτά για αυτό ...

Η φιλοσοφική μου αναζήτηση επικεντρώνεται όμως στο τί μου δίνει το linq σε σχέση με data access σε RDBMS. Τί μου δίνει που δεν έχω εκτός απο compile-time safety; Πάντα λαμβάνω υπ' όψην οτι έτσι κι αλλιώς, αυτό το compile-time safety δεν το θεωρούσα ποτέ δεδομένο στο traditional data access. Και τί έγινε που το έχω τώρα; ( Πάντα χωρίς vNext μιλώντας )

Ένα ακόμη ερωτηματικό μου, είναι οτι έχοντας τα linq queries μου compiled στον κώδικά μου, δε χάνω το "δυναμισμό" που μπορεί να μου δώσει η χρήση SQL; Π.χ. ... στην πλατφόρμα που αναπτύσουμε, έχω τη δυνατότητα να τρέχω διαφορετικό SQL ανά ρόλο του εκάστοτε χρήστη, με κάποιο τρόπο. Μπορώ επίσης @ runtime να αλλάζω αυτά τα queries, ανάλογα με την ανάγκη που παρουσιάζεται σε συγκεκριμένες εγκαταστάσεις. Αν τα queries μου ήταν compiled με το υπόλοιπο code base, δεν χάνω απο 'κει ένα μεγάλο flexibility;

Αντίθετα, όσον αφορά το in-memory querying, to linq έρχεται να μου δώσει μια πραγματικά πολύ βολική λύση, και φιλικότερο syntax. Εκεί βλέπω να επικεντρώνεται η ουσία του linq. Where no-one has gone before.

---

Angel
O:]

Φίλε anjelinio θα συμφωνήσω απόλυτα μαζί σου όσον αφορά το κομμάτι του in-memory (επιτέλους το prevayler θα αποκτήσει query functionality :) ).

Τώρα για το dynamic κομμάτι του LINQ.  Σου επιτρέπει να διαχειρίζεσαι ξεχωριστά τα Lambda Functions που αποτελούν το query σου και μάλιστα έχει την δυνατότητα να παίρνεις ολόκληρο το Syntax Tree (Expression trees) και να το διαμορφώνεις όπως εσύ θέλεις.

---

Palladinos Nick
Software Engineer
-----------------------
The limits of my language mean the limits of my world. (Ludwig Wittgenstein)

"linq μόνο για in-memory querying και προσεχτικά με τη βάση, ή πάμε αβέρτα κι οποιον πάρει ο χάρος;;;"

Νομιζω οτι η πρωτη περιπτωση ειναι και η πιο σωστη, αν και αυτο βεβαια ειναι υποκειμενικο για τον καθενα.

Συμφωνω κι εγω με τον φιλο anjelinio, αν και στη δουλεια μας επανω, πολλες φορες βλεπουμε καχυποπτα κατι καινουριο (σιγουρα το να παρεις τη δουλεια ή μερος αυτης απο το rdbms που πολλοι απο εμας εχουν συνηθισει να την κανουν εκει δεν ειναι και οτι πιο συνηθισμενο...) αλλα πολλες φορες αργοτερα το υιοθετουμε.

---

Software Engineer, specializes in Microsoft .net/C#, COM, Sql Server and now Python.

PALLADIN wrote:

Τώρα για το dynamic κομμάτι του LINQ.  Σου επιτρέπει να διαχειρίζεσαι ξεχωριστά τα Lambda Functions που αποτελούν το query σου και μάλιστα έχει την δυνατότητα να παίρνεις ολόκληρο το Syntax Tree (Expression trees) και να το διαμορφώνεις όπως εσύ θέλεις.

 .. ω ρε γαμώτο ... πρέπει να βρώ χρόνο για διάβασμα λέμεεεε ... :D

Thanx nick, δεν το είχα δεί αυτο.

---

Angel
O:]

Λοιπόν, διάβασα ! :D Σε ένα καταπληκτικό blog post, ο κύριος Matt Warren εξηγεί τα πάντα :) Dynamic queries @ runtime 101 !

---

Angel
O:]

... και εγώ προσωπικά περιμένω "σαν το κοράκι" να γίνει mainstream η C# 3.0 ακριβώς γι'αυτό: το να πάρεις το syntax tree ενός λ και να μπορείς να το μεταφράσεις σε Javascript, αλλά να μπορείς να το εκτελέσεις και μέσα στο CLR. (Εκτιμώ πολύ τον Philip Wadler αλλά δε θέλω να πάω στο Links)

Τρέχει στο pre-release (για το υποσύνολο των εκφράσεων της C# που έκρινα απαραίτητο) αλλά βέβαια δεν μπορεί να μπει σε εφαρμογές πελάτη. (Ενδιάμεση λύση προς το παρόν: Spring expressions για το server και string με Javascript expression για τον client)

---

--
D. Souflis
"Reality is that which, when you stop believing in it, doesn't go away" P. K. D.

Καλησπέρα φιλε μου

Ο Erik Meijer (άλλος ένας από τους designers της Haskell) δουλεύει πάνω στο LINQ 2.0 !!!!... και η ιδέα είναι παρόμοια με του LINKS

Check it out

Democratizing the Cloud

---

Palladinos Nick
Software Engineer
-----------------------
The limits of my language mean the limits of my world. (Ludwig Wittgenstein)

Ενδιαφέρον, δεν ήξερα ότι ο Meijer προέρχεται από τη Haskell.

Στο συγκεκριμένο πεδίο υπάρχει μεγάλη εμπειρία από πολλούς "παίκτες" (π.χ. Hibernate) και το πιθανότερο είναι να γίνουν απλώς LINQ-aware. Πράγμα που μόνο καλό θα κάνει (κατά τη γνώμη μου) γιατί όσο περισσότερες λύσεις υπάρχουν για ένα πρόβλημα, τόσο η εξέλιξη των λύσεων είναι πιο γρήγορη.

---

--
D. Souflis
"Reality is that which, when you stop believing in it, doesn't go away" P. K. D.

Καλημέρα, έψαχνα το θέμα και ευτυχώς πέφτω σε εσάς...

Αν καταλαβαίνω καλά, το Ο/R δουλεύει κάπως έτσι ;

1) Φτιάχνω την βάση. Πινακες, σχέσεις τα πάντα.Το σχήμα.
2) Με Nhibernate, κάνω τις ιδιότητες των πινάκων αντιστοίχηση (map) σε τύπους που αντιστοιχούν π.χ. C#
3) Φτιάχνω κλάσσεις που μέσω του 2ου επιπέδου βλέπουν την βάση, και οι κλάσσεις είναι και πίνακες π.χ. Client (κλάσση)--->tblClient(πίνακας)

Είναι έτσι ;

Αν ναι, τότε απορία...με τι τρόπο θα παράγω το map? Χεράτα!!?!?!?!??!?! Και οι κλάσσεις που είναι εικόνα των πινάκων...Πάλι χεράτα?!?!?!?!?!?!
Στο δίκτυο εχω βρεί εργαλεία generators αλλά δεν ξέρω αν το χω καταλάβει εξαρχής το νόημα...
Πάντως αν αυτό το πράγμα λειτουργεί και δεν υπάρχει μεσάζων που να σου κάνει την δουλεια, απο πίνακα...εν'τέλει σε κλάσση, τοτε γιατι να φάς την ώρα σου σε μια τέτοια λύση δεν καταλαβαίνω το λόγο...

Παρακαλώ διορθώστε με, γιατί σίγουρα κάτι εχω παρεξηγήσει....

Η αλήθεια είναι ότι δεν δουλεύουν όλα τα ORM με τον ίδιο τρόπο, ούτε εξυπηρετούν τον ίδιο τρόπο ανάπτυξης.
Το best practice για το NHibenrate δεν είναι να ξεκινάς την ανάπτυξη από την "βάση", αλλά από το Domain (όχι ότι δεν δουλεύει καλά και έτσι), αν θέλεις να ακολουθήσεις την ανάπτυξη ξεκινώντας από την βάση θα σου πρότεινα το ActiveRecord  ή και το Subsonic  (και πολλά άλλα....)
Στο internet μπορείς να βρεις πολλά tutorials, ένα καλό είναι το NHibernate and Domain Driven Design , και εδώ αν ψάξεις θα βρεις πολλές συζητήσεις για το θέμα.

Όπως κατάλαβες τις περισσότερες φορές θα χρησιμοποιείς generators σαν το codesmith και το mygeneration με έτοιμα templates, υπάρχουν φυσικά και visual εργαλεία όπως το  objectmapper .
Τώρα στο δύσκολο ερώτημα "γιατί;" ....    μια πολύ "απλουστευμένη" δικαιολογία είναι, ότι αφού προγραμματίζουμε με objects, θα ήταν καλύτερα και ποιο εύκολα να είχαμε τα data μας σαν object, δύσκολο όμως γιατί οι βάσεις είναι σχεσιακές, άρα θέλουμε μια "εύκολη" αντιστοίχηση (αυτό κάνει το ORM). Απο κει και πέρα υπάρχουν και πολλοί άλλοι λόγοι όπως support Domain/Model Driven Design, Layered Applications, easy configuration for different databases και πολλά άλλα καθένα από τα οποία είναι πολύ σημαντικό και μεγάλο κεφάλαιο στην ανάπτυξη.

---

Nikos Κ.
ALT.NET

Σε ευχαριστώ... :-) κοιτάζω τις αναφορές, αν και στην δουλειά μου είπαν οτι το ORM είναι κάτι που χρειάζεται συνεχή επίβλεψη, δεν είναι πολύ αξιόπιστο αν δεν έχεις  αρκετή εμπειρία και καλό μπακγκράουντ.. εγώ πάντως το τσεκάρω...