ADO.NET

Απ: Εntitydatasource vs Objectdatasource

George J. Capnias — Fri, 20 Apr 2012 02:21:23 GMT

koslyr:
Παναγιώτης Καναβός:
Δεν υπάρχει λόγος να χρησιμοποιήσεις κανένα datasource.

Από διάφορα ενδεικτικά παραδείγματα που διάβασα για το EF, χρησιμοποιούσαν τα περισσότερα το EntityDataSource.
Από οτι κατάλαβα ως καλύτερο best practise για την υλοποίηση του DAL προτείνετε την χρήση του EF χωρίς το EntityDataSource control και όλα τα CRUD operations να γίνονται manually μέσω του databinding απευθείας στα data-bound controls;

Έχω μια εντύπωση ότι υπάρχει αυτό το μπρος-πίσω των ερωτήσεων, γιατί απλά όλοι θεωρούν ότι υπάρχει DAL που συνδέεται στο interface. Αυτό δεν είναι αληθοφανές παράδειγμα - εκτός αν είναι τόσο "κουτή" η εφαρμογή που θέλεις να φτιάξεις. Κάπου πρέπει να υπάρχει και λίγο intelligence - το BI, ή business logic, ή όπως αλλιώς θες να το πεις:

Αν αυτό που σε ενδιαφέρει είναι να βγάζεις πίνακες σε οθόνες, έχεις πάρει λάθος δρόμο - χρησιμοποίησε το Dynamic Data, βάλε από πίσω LINQ2SQL ή EF, ή και ένα WCF Data Service, όλα γίνονται αυτόματα και δεν χρειάζεται να γράψεις τίποτα, θα βγάλεις οθόνες σε dt -> 0.
Αν σε ενδιαφέρει να γράψεις LOB εφαρμογή θα πρέπει μέσα στο πλάνο σου να υπάρχει και το business logic, καλό θα είναι να το δεις σε συνδιασμό με κάποιο pattern ανάπτυξης - αν το στοιχείο σου είναι τα ASP.NET WebForms, πρέπει να δεις κάτι που να σου ταιριάζει. πχ το ASP.NET Web Forms MVP (http://webformsmvp.com/)

George J.

Απ: Εntitydatasource vs Objectdatasource

koslyr — Thu, 19 Apr 2012 16:47:12 GMT

Παναγιώτης Καναβός:
Δεν υπάρχει λόγος να χρησιμοποιήσεις κανένα datasource.

Από διάφορα ενδεικτικά παραδείγματα που διάβασα για το EF, χρησιμοποιούσαν τα περισσότερα το EntityDataSource.
Από οτι κατάλαβα ως καλύτερο best practise για την υλοποίηση του DAL προτείνετε την χρήση του EF χωρίς το EntityDataSource control και όλα τα CRUD operations να γίνονται manually μέσω του databinding απευθείας στα data-bound controls;

Απ: Εntitydatasource vs Objectdatasource

Παναγιώτης Καναβός — Tue, 17 Apr 2012 23:12:09 GMT

Νίκο, μπορείς άνετα να κάνεις databinding επάνω στο List<string>. Δεν υπάρχει λόγος να χρησιμοποιήσεις κανένα datasource.

Απ: Εntitydatasource vs Objectdatasource

Παναγιώτης Καναβός — Tue, 17 Apr 2012 22:47:39 GMT

Αυτό που λες είναι η "κακή" μέθοδος. ΔΕΝ ΘΕΛΩ ΜΕ ΤΙΠΟΤΕ να γίνει κάτι σαν το Rent επειδή πείραξα κάποιες τιμές σε κάποιο grid.

Αν κάποιος θέλει να κάνει Rent το σωστό θα είναι να διαλέξει μία εντολή "Rent" η οποία θα καλέσει την αντίστοιχη μέθοδο Rent σε ένα αντικείμενο και εκεί πίσω θα εκτελέσει τη business λογική που απαιτείται (έλεγχος μοντέλου, δέσμευση, αποστολή επιβεβαίωσης στον πελάτη, δημιουργία work order για την προετοιμασία του αυτοκινήτου, ειδοποίηση στο λογιστήριο για την δημιουργία της χρέωσης, δημιουργία ασφαλιστήριου κλπ.)

Παρότι μπορείς με 5 τούμπες και ολίγη διαστροφή να χώσεις όλη αυτή τη λογική σε ένα UpdateMethod, είναι μία πολύ κακή τακτική.

Απ: Εntitydatasource vs Objectdatasource

nikolaosk — Tue, 17 Apr 2012 22:47:11 GMT

Γενικότερα δεν τα χρησιμοποιώ τα datasources για τους λόγους που αναφέρεις.Όπως και να το κάνεις δεν συμφωνούν με τα software patterns.Χρησιμοποιώ το EF χωρίς τα datasources εκτός από ελάχιστα πολύ μικρά Projects....

Συμφωνώ με αυτό που λες εδώ

"Το σίγουρο είναι ότι το EntityDataSource ΔΕΝ αφορά σε καμμία απολύτως περίπτωση το business logic, ούτε έχει να κάνει τίποτε με code reuse"

το ίδιο λέω και εγώ στο δικό μου σχόλιο....

"Με το EntityDataSource μπορείς να υλοποιήσεις πολύ γρήγορα την web forms εφαρμογή σου. Στην ουσία γράφεις όλο το Business logic & data access logic στις .aspx σελίδες σου...Όπως καταλαβαίνεις δεν υπάρχει καθόλου code reuse..."

Μάλλον δεν ήμουν αρκετά σαφής. Δεν είναι ο καλύτερος τρόπος να κάνεις code reuse (αν μπορείς να το πεις code reuse) χρησιμοποιώντας το ObjectDataSource. Αλλά π.χ σε αυτό εδώ το blog post μου δείχνω ότι σε σχέση με το EntityDataSource/LinqDataSource μπορώ να "γράψω" ένα καλύτερο """""data access layer""""" με ObjectDatasource

Π.χ φτιάχνω ένα DAL.cs class file και γράφω π.χ μια μέθοδο

 public List<String> GetCities()
    {
        using (var ctx = new PubsDataContext())
        {
 
            var query = (from auth in ctx.authors
                        select auth.city).Distinct().ToList();
 
            return query;
 
 
 
        }

και μετά το δένω με το ObjectDataSource την DAL κλάσση και τις μεθόδους της.Αν π.χ κάτι πάει λάθος ξέρω ότι πρέπει να ψάξω στο DAL.cs. είναι ένα καλύτερο ""seperation of concerns"".

θα μου πεις, που είναι το code reuse? Σε ένα παραπλήσιο project μπορείς να κάνεις copy-paste το DAL.cs και να αλλάξεις π.χ την GetCities Και να την κάνεις GetOrders και να αλλάξεις τον κώδικα κατάλληλα.

Δεν είναι βέβαια αυτό ένα γνήσιο code reuse και δεν γίνεται implement με τον τρόπο αυτό....Υπάρχουν ασφαλώς πολύ καλύτεροι τρόποι να το κάνεις. δεν είμαι λοιπόν θιασώτης αυτής της λύσης....απλά μιλούσα για την σύγκριση EntityDataSouce vs ObjectDataSource

Δεν θα διάλεγα πάντως (data sources) για να κάνω ένα σοβαρό enterprise application.Συμφωνώ ότι το EF δεν τα χρειάζεται και η δουλειά μας γίνεται με databinding.

Απ: Εntitydatasource vs Objectdatasource

Markos — Tue, 17 Apr 2012 20:30:53 GMT

Αυτή είναι η λογική του ότι τα Update και Delete methods έχουν να κάνουν με τη βάση. Στην ουσία έχουν να κάνουν με το control της φόρμας και τα commands που εκτελούνται εκεί. Θυμάσαι ένα thread που άνοιξε για crosstab editing σε Lightswitch; Δοκίμασα να δω αν μπορεί να γίνει σε ASP.NET (ναι - ναι, με datatables). Βεβαίως και ΔΕΝ χρησιμοποίησα database table με ορθογώνιες διαστάσεις (n x m) γιατί κάτι τέτοιο θα είχε ως αποτέλεσμα το table να μεγαλώνει ανεξέλεγκτα με κάθε νέα εγγραφή, για κάθε μία από τις διαστάσεις του (χώρια του ότι κάθε προσπάθεια "συντήρησης" της "ορθογωνιότητας" θα ήταν σκέτο μελόδραμα). Έφτιαξα, λοιπόν, ένα dummy datatable στο οποίο έκανα το crosstab και το "έδεσα" σ' ένα gridview. Το μόνο action που είχε νόημα πια ήταν το "Update" (για το control). Στη βάση τα πράγματα ήταν διαφορετικά. Αν στο κελί υπήρχε τιμή και αυτή άλλαζε, τότε είχαμε update του record. Αν στο κελί γινόταν διαγραφή τιμής, "εισάγοντας" ένα "κενό" string, τότε στη βάση το συγκεκριμένο record διαγραφόταν. Τέλος, αν σε κενό κελί γινόταν εισαγωγή τιμής, τότε στη βάση είχαμε insert. Το ObjectDataSource συμπεριφέρθηκε άψογα, ανάλογα με τις τιμές των παραμέτρων που περνούσα στην UpdateMethod (DeleteMethod δεν υπήρχε γιατί δεν είχε νόημα). Αυτό που περιγράφω, σε τι διαφέρει από το rent action; Αν κατάλαβα καλά, θέλεις με edit στο grid να κάνεις insert στη βάση (νέο rent). Αυτό είναι κάτι που μπορεί να γίνει.

Βέβαια, η όλη συζήτηση έχει "ακαδημαϊκό" χαρακτήρα και όχι να πείσει για το αν η χρήση ή η μη χρήση του ObjectDataSource αποτελεί σωστή πρακτική. Δόξα τω θεώ, υπάρχουν πολλές εναλλακτικές προσεγγίσεις για το ίδιο πρόβλημα.

Απ: Εntitydatasource vs Objectdatasource

Παναγιώτης Καναβός — Tue, 17 Apr 2012 18:42:44 GMT

Αυτά τα CRUD operations δεν "βρωμάνε" σε μία κλάση που σκοπό έχει να παρουσιαστεί στην οθόνη? Στο παράδειγμα της ενοικίασης αυτοκινήτου, τί νόημα θα είχε η UpdateMethod? Τα "απλά" signatures της ObjectDataSource στην πραγματικότητα κρύβουν DAL κώδικα τον οποίο απλά θα πρέπει να γράψεις εσύ, δεν θα στον δημιουργήσει το ίδιο το datasource.

Όσο για το "κάνεις ότι θες" δείχνει το μέγεθος του προβλήματος. Ενώ αυτό που θέλω να κάνω είναι μία ενοικίαση, η οποία κατά προτίμηση θα λέγεται Rent(), αναγκάζομαι να φτιάξω μία update, με ένα μάτσο παραμέτρους που δεν χρειάζομαι, η οποία θα πρέπει να "μαντεύει" ότι σε αυτή τη φόρμα θέλω να κάνω ενοικίαση και ΟΧΙ καταχώρηση νέου αυτοκινήτου. Ενώ θα μπορούσα να καθαρίσω με μία Car.Rent(Customer), θα αναγκαστώ να περάσω πράγματα μόνο και μόνο για να ικανοποιηθεί η UpdateMethod.

Για σκέψου η ενοικίαση να γίνεται καλώντας ένα web service αντί για update στη βάση. Θα πρέπει να φτιάξω καινούρια φόρμα? Γιατί?

Και το θέμα είναι ότι τίποτε από αυτά δεν είναι απαραίτητο. Το ObjectDataSource ΔΕΝ μου δίνει κάτι επιπλέον σε σχέση με το απλό data binding και της χρήση του οποιουδήποτε ORM.

Disclaimer: Όπως όλοι, κάθε φορά που βγαίνει ένα νέο datasource λέω κι εγώ να το χρησιμοποιήσω και μετά καταριέμαι την ώρα και τη στιγμή. Τελευταία γκάφα ήταν η χρήση του EntityDataSource σε Silverlight πριν κανα χρόνο, για να μιλήσω με WCF Data Services, επειδή βαριόμουν τις ασύγχρονες κλήσεις. Εκεί διαπίστωσα τί πλάκα έχει να συνδέσεις ένα Grid, pager και property grid πάνω σε ένα datasource, το οποίο αποφασίζει ξαφνικά να γυρίσει σε edit mode χωρίς να σου το πει. ΜΠΛΙΑΧ!

Απ: Εntitydatasource vs Objectdatasource

Markos — Tue, 17 Apr 2012 18:12:30 GMT

Παναγιώτης Καναβός:
Ειδικά το ObjectDataSource προσπαθούσε να κρύψει την έλλειψη (τότε) κάποιου ORM στο χώρο του .NET, παρέχοντας πρόσβαση σε "Business Objects" τα οποία κρύβαν πίσω τους τον data access κώδικα, αλλά έπρεπε να "βγάζουν" προς τα έξω κάποιες CRUD μεθόδους. Προφανώς δεν έπιασε ούτε αυτό, καθώς τελικά δεν διευκόλυνε σε κάτι. Το μανίκι είναι η λογική και ο data access κώδικας, όχι πως θα καλέσεις τα CRUD!
Άσε που σε σχέση με τα ORMs, το ObjectDataSource σε αναγκάζει να "βρωμίσεις" τις κλάσεις σου με κώδικα που δεν έχει θέση σε αυτές.

Παναγιώτη, μπορείς να το αναπτύξεις αυτό λίγο περισσότερο; Στο ObjectDataSource δεν είναι υποχρεωτικό να δηλώσεις data access κώδικα. Απλά signatures για SelectMethod, UpdateMethod και DeleteMethod. Δεν είναι υποχρεωτικό να υπάρχει κάποιο query μέσα σ' αυτές. Αρκεί να περάσεις τις κατάλληλες παραμέτρους, οι οποίες πρέπει να ταιριάζουν με το sugnature, και κάνεις ό,τι θες, κατευθύνοντας το action εκεί που θες εσύ, χωρίς να χρειάζεται να "αντιγράψεις" τα παραδείγματα του MDSN. Γιατί, λοιπόν, να "βρομίσω" τις κλάσεις μου; Αντίθετα, το Select property του EntityDataSource περιμένει ένα Select statement, οπότε εδώ τα πράγματα είναι διαφορετικά.

Απ: Εntitydatasource vs Objectdatasource

Παναγιώτης Καναβός — Tue, 17 Apr 2012 17:36:25 GMT

Η σύγκριση είναι λάθος, καθώς το Entity Framework (ή οποιοδήποτε άλλο ORM) δεν απαιτεί τη χρήση κανενός είδους "xxxDataSource". Ουσιαστικά τα datasources είναι ένα anti-pattern (δηλ. πάρα πολύ κακή συνήθεια) η οποία προσπαθεί να περάσει στο χώρο του object-oriented programming τεχνικές που είχαν εφαρμογή μόνο στις εφαρμογές data entry της προ-προηγούμενης δεκατετίας (1990s).

Τότε κύρια ανησυχία ήταν πως θα φτιάξεις πιο γρήγορα κάποιες data entry φόρμες. Τα διάφορα sources διευκολύνανε την επικοινωνία με τη βάση κρύβοντας τον τρόπο και την SQL από προγραμματιστές που δεν ήξεραν SQL. Η κατάσταση βελτιώθηκε αρκετά γρήγορα με το .NET 2.0 και τα διάφορα datasources έχασαν την όποια αξία τους. Άσε που ο κώδικας που παρήγαν οι προγραμματιστές "που δεν ξέραν SQL" δημιουργούσε φοβερά προβλήματα σε όλα τα client-server συστήματα της εποχής και συνεχή κλειδώματα ακόμα και για λίγους χρήστες.

Αργότερα όμως εμφανίστηκε η ανάγκη να μπορείς να υλοποιήσεις πιο περίπλοκες συμπεριφόρες που αγγίζανε 2-3 διαφορετικές οντότητες (φαντάσου πχ. την ενοικίαση ενός αυτοκινήτου). Επιπλέον, ο αριθμός των χρηστών αυξήθηκε πέρα από τους .... 5 και προφανώς δεν μπορούσε κανείς να ισχυριστεί ότι θα μπορούσε να γράψει φόρμες αγνοώντας την πρόσβαση στη βάση.

Ακόμα και τότε, τα datasources ήταν αποτυχία και κανείς δεν τα χρησιμοποιούσε σε σοβαρές εφαρμογές.

Τα διάφορα .NET datasources εμφανίστηκαν στις πρώτες εκδόσεις του .NET για να διευκολύνουν τη γρήγορη δημιουργία φορμών, στο στυλ των sources που χρησιμοποιούσε η VB6. Τω καιρώ εκείνω, το data binding ήταν πολύ πιο δύσκολο και φασαριόζικο. Ουσιαστικά ήταν μία προσπάθεια να κρύψουν την απαιτούμενη SQL, τον ADO.ΝΕΤ κώδικα και το data binding. Εσύ "απλά" θα "σχεδίαζες" το query. Η αποτυχία τους ήταν πλήρης, ακόμα και στην VB6, καθώς για να κάνεις κάτι πέρα από toy εφαρμογή χρειάζεται να ασχοληθείς σοβαρά και με την SQL και με τον κώδικα του data access. Επιπλέον, η ίδια η φιλοσοφία των datasources δημιούργησε προβλήματα, καθώς σε ανάγκαζαν να "χώσεις" θέματα χαμηλού επιπέδου μέσα στο ίδιο το UI.

Ειδικά το ObjectDataSource προσπαθούσε να κρύψει την έλλειψη (τότε) κάποιου ORM στο χώρο του .NET, παρέχοντας πρόσβαση σε "Business Objects" τα οποία κρύβαν πίσω τους τον data access κώδικα, αλλά έπρεπε να "βγάζουν" προς τα έξω κάποιες CRUD μεθόδους. Προφανώς δεν έπιασε ούτε αυτό, καθώς τελικά δεν διευκόλυνε σε κάτι. Το μανίκι είναι η λογική και ο data access κώδικας, όχι πως θα καλέσεις τα CRUD!
Άσε που σε σχέση με τα ORMs, το ObjectDataSource σε αναγκάζει να "βρωμίσεις" τις κλάσεις σου με κώδικα που δεν έχει θέση σε αυτές.

Το EntityDataSource είναι μία προσπάθεια να δημιουργηθεί ένα πιο εξελιγμένο ObjectDatasource , πάνω από ένα ORM, το Entity Framework. Επιλέγεις τις οντότητες σου, άντε δίνεις και το LINQ query, και αυτό φτιάχνει τις αντίστοιχες κλήσεις στο ORM. Χονδρικά είναι ένα ObjectDataSource στο οποίο "δεν χρειάζεται" να γράψεις τα CRUD. Άλλη μία αποτυχία γιατί:

Τα αντικείμενα ΔΕΝ έχουν σχέση με το CRUD αλλά να παρέχουν μεθόδους ανωτέρου επιπέδου. Φαντάσουν ένα αντικείμενο "Αυτοκίνητο" το οποίο περιέχει μία μέθοδο που λέγεται "Ενοικίαση".
Σου πετάει το ORM μέσα στη φόρμα
Σε περιορίζει στα queries που μπορείς να κάνεις
Σε περιορίζει στο είδος των validation ή άλλων ενεργειών που θέλεις να κάνεις. Άλλο ένα action που λέει "ενοικίαση" και άλλο τα πολλαπλά updates που απαιτούνται σε διάφορες οντότητες για να υλοποιηθεί η ενοικίαση ενός αυτοκινήτου.
Ουσιαστικά αντιστρέφει (διαστρέφει θα έλεγα) τη λειτουργία του ORM. Εκεί που κατάφερες να μεταφέρεις αλλού τον data access κώδικα, σου τον ξαναφέρνει στη μούρη!

Η κατάληξη είναι ότι δεν χρειάζεσαι κανένα datasource. Όλα τα data controls του ASP.NET υποστηρίζουν data binding σε αντικείμενα, οπότε από τη στιγμή που έχεις φορτώσει το αντικείμενο σου, μπορείς να το δείξεις.

Νίκο, νομίζω έχεις μπερδέψει τί κάνει το Entity Framework και τί κάνουν τα ObjectDataSource και EntityDataSource.

Το σίγουρο είναι ότι το EntityDataSource ΔΕΝ αφορά σε καμμία απολύτως περίπτωση το business logic, ούτε έχει να κάνει τίποτε με code reuse. Επίσης, το ObjectDatasource είναι εντελώς περιττό από τη στιγμή που υπάρχει data binding.

Η κουβέντα για layers και MVC pattern πάντως δεν έχει καμμία απολύτως θέση σε αυτή τη συζήτηση, καθώς αφορά τη σχεδίαση μίας εφαρμογής σε πολύ ανώτερο επίπεδο από το data access. Σα να λέμε όχι μήλα και μηλόπιτα, αλλά μήλα και σπάτουλα ...

Απ: Εntitydatasource vs Objectdatasource

nikolaosk — Sun, 15 Apr 2012 04:19:19 GMT

Με το EntityDataSource μπορείς να υλοποιήσεις πολύ γρήγορα την web forms εφαρμογή σου. Στην ουσία γράφεις όλο το Business logic & data access logic στις .aspx σελίδες σου...Όπως καταλαβαίνεις δεν υπάρχει καθόλου code reuse....Εϊναι λύση για πολύ μικρές εφαρμογές σχετικά απλές που δεν θα "μεγαλώσουν" πολύ στο μέλλον...Με τον τρόπο αυτό δεν γράφεις τον κώδικα σε layers/tiers.Ένας τρόπος να γράψεις τον κώδικα σου με καλύτερο τρόπο είναι αντί για το EntityDataSource control να χρησιμοποιήσεις το ObjectDataSource control.Με τον τρόπο αυτό γράφεις εσύ τον κώδικα για το DAL. Γράφεις τον κώδικα για το select,insert,update,delete αλλά μπορείς (επειδή γράφεις εσύ τον κώδικα) να γράψεις στην delete() μέθοδο ότι κώδικα θέλεις π.χ όταν κάνεις delete ένα row αυτό να πάει σε ένα άλλο Archive πίνακα.

Αν θες να δεις ένα blog post μου που υλοποιώ μια απλή εφαρμογή με LINQ to SQL & το ObjectDataSource control δες εδώ . Εδώ μπορείς να δεις ένα blog post μου πως χρησιμοποιήσεις το EntityDataSource control.

Αν θες να δεις πως χειριζόμαστε CRUD operations στις ASP.Νet MVC applications , σου συνιστώ ανεπιφύλακτα να δεις αυτά εδώ τα tutorials.

To MVC pattern υλοποιεί εκ φύσεως πολύ καλύτερα αυτό που λέμε seperation of concerns. Αν θες να δεις ένα απλό παράδειγμα δες εδώ .

Απ: Εntitydatasource vs Objectdatasource

koslyr — Sun, 15 Apr 2012 03:09:09 GMT

Παναγιώτης Καναβός:
Αν χρησιμοποιήσεις ένα ώριμο OR Mapper (NHibernate, Entity Framework) γλυτώνεις εντελώς τη δημιουργία του CRUD κώδικα. Αν χρησιμοποιήσεις μετά τις δυνατότητες templating και scaffolding που σου παρέχουν διάφορα frameworks αλλά και αυτά τα ίδια τα built-in ASP.NET controls γλυτώνεις και όλο τον επαναλαμβανόμενο κώδικα στο UI. Μάλιστα το Dynamic Data στο ASP.NET και η αντίστοιχη δυνατότητα στο MVC σου επιτρέπουν να δημιουργήσεις πολύ εύκολα UI από ένα entity model που έχει δημιουργηθεί με Entity Framework ή NHibernate

Ανάμεσα στις δυο υλοποιήσεις (Εntitydatasource ή Objectdatasource) για το DAL, ποία χρησιμοποιείται πλέον περισσότερο;
Από ότι έχω καταλάβει με το Εntitydatasource γλιτώνεις το όλο κομμάτι του CRUD κώδικα, αλλά δεν γνωρίζω με ποιο ενδεχομένως trade-off συγκριτικά με το Objectdatasource.
Προς το παρον στο πλαίσο των Web-Forms προσπαθώ να διαπιστώσω τα pros&cons σχετικά με το Εntitydatasource vs Objectdatasource.
Για την υλοποίηση Web Apps μέσω MVC στο θέμα του DAL υφίστανται ξανά οι ίδιοι προβληματισμοί ή έχουν πιο ξεκάθαρα patterns για την εκτέλεση του DAL;

Απ: Best Practise για GRUD operation

Markos — Fri, 13 Apr 2012 04:44:11 GMT

Ανοίξαμε μεγάλο θέμα. Προσωπικά, θέλω να έχω τον έλεγχο πάνω στα T-SQL scripts. Το μεγαλύτερο πρόβλημα για μένα είναι το "βάθος" του inheritance. Η υλοποίηση με views για τα selects και stored procedures για updates, inserts και deletes ταιριάζει περισσότερο στην "ιδιοσυγκρασία" μου. Συνεχίζω να θεωρώ τα datasets ως το καλύτερο κομμάτι του ADO.NET μέχρι σήμερα. Υπάρχουν πολλοί τομείς πάνω στους οποίους η Microsoft θα μπορούσε να τα βελτιώσει. Για παράδειγμα, η παρούσα υλοποίηση περιέχει πολύ presentation κώδικα που είναι περιττός στον server. Θα μπορούσαμε να έχουμε ένα lite datatable object για τον server και το γνωστό datatable για τον client. Έχω σκεφτεί κι άλλα πολλά, αλλά η Microsoft τα έχει εγκαταλείψει...

Απ: Best Practise για GRUD operation

nikolaosk — Fri, 13 Apr 2012 04:11:47 GMT

θα δω αυτά που μου προτείνεις.Oμολογώ ότι δεν τα έχω δει και δεν μπορώ να κάνω σύγκριση.Εκτιμώ ότι είναι έτσι όπως τα λες. Πλέον χρησιμοποιώ το EF αρκετά ειδικά τώρα που έχει ωριμάσει σαν framework και υποστηρίζει όλα τα data types καθώς και το Code First Approach.

Έχω κάνει τα τελευταία 2-3 χρόνια projects χρησιμοποιώντας το Enterprise Library και γενικά μου έλυσε τα χέρια.Θα δω το log4net για ένα νέο project που έχω.

Απ: Best Practise για GRUD operation

nikolaosk — Fri, 13 Apr 2012 04:02:36 GMT

Αν θες νας δεις μια μικρή εφαρμογή (asp.net web forms) που είχε αναπτυχθεί σαν sample application στο asp.net website ,πάτα εδώ ,

Μπορείς να κατεβάσεις το project αυτό τοπικά και να δεις πως υλοποιούνται τα CRUD operations. Χρησιμοποιεί το Database First model.

Απ: Best Practise για GRUD operation

koslyr — Fri, 13 Apr 2012 03:35:11 GMT

Παναγιώτης Καναβός:
Αν χρησιμοποιήσεις ένα ώριμο OR Mapper (NHibernate, Entity Framework) γλυτώνεις εντελώς τη δημιουργία του CRUD κώδικα. Αν χρησιμοποιήσεις μετά τις δυνατότητες templating και scaffolding που σου παρέχουν διάφορα frameworks αλλά και αυτά τα ίδια τα built-in ASP.NET controls γλυτώνεις και όλο τον επαναλαμβανόμενο κώδικα στο UI. Μάλιστα το Dynamic Data στο ASP.NET και η αντίστοιχη δυνατότητα στο MVC σου επιτρέπουν να δημιουργήσεις πολύ εύκολα UI από ένα entity model που έχει δημιουργηθεί με Entity Framework ή NHibernate

Παναγιώτη για web application με web forms έχεις να μας δώσεις κάποιο αντιπροσωπευτικο link για την υλοποίηση που αναφέρεις με το Entity Framework ή NHibernate.
Θεωρεις πλέον ότι πρέπει να χρησιμοποιούμε αυτές τις τεχνικές για το CRUD κώδικα;
Επίσης θεωρείς σωστή την προσσέγιση να καλούνται όλα αυτά τα GRUD operation (ανεξάρτητα με τον τρόπο που υλοποιούνται) μέσω Ajax Call και όχι με τον κλασικο τρόπο;