Ξέχασα ίσως το πιο σημαντικό. Ο manager αυτός κάνει sql code generation για την επικοινωνία με τη βάση και αναλαμβάνει να δημιουργήσει κώδικα κατάλληλο για sql server ή oracle. Κάνει χρήση του sqlcommandbuilder ή oraclecommandbuilder με κάποιες τροποποιήσεις για τα autoincrement πεδία του sql server.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

papadi wrote:

Η κλάση αρχικοποιείται κάθε φορά από την αρχή για την αποθήκευση ενός dataset, μια φορά όμως αν το dataset περιέχει πολλές εγγραφές σε πολλούς πίνακες. Οπότε δεν είναι singeton ή shared, αλλά καθαρά instances κάθε φορά, μια που δεν έχουν state.

Ωπ. Να μια αφορμή για ερώτηση: Αφού έχεις stateless πράγματα, γιατί δεν φωνάζεις shared methods μιας κλάσης που ΔΕΝ χρησιμοποιεί shared members; Γιατί αρχικοποιείς κάθε φορά ένα ολόκληρο object μόνο για ένα single call; (Ερώτηση είναι, πραγματικά, οχι κριτική). Εκτός βέβαια και αν κινείσαι με βάση την πρόβλεψη οτι θα σου επιτρέψει αυτή η υλοποίηση να προσαρμοστείς και σε πιό σκληρά σενάρια (com+, remoting και δεν συμμαζεύεται).

Γενικά, τι σε ώθησε να χρησιμοποιήσεις instances για αυτή τη λειτουργία;

 

 

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

cap wrote:

papadi wrote: Η κλάση αρχικοποιείται κάθε φορά από την αρχή για την αποθήκευση ενός dataset, μια φορά όμως αν το dataset περιέχει πολλές εγγραφές σε πολλούς πίνακες. Οπότε δεν είναι singeton ή shared, αλλά καθαρά instances κάθε φορά, μια που δεν έχουν state. Ωπ. Να μια αφορμή για ερώτηση: Αφού έχεις stateless πράγματα, γιατί δεν φωνάζεις shared methods μιας κλάσης που ΔΕΝ χρησιμοποιεί shared members; Γιατί αρχικοποιείς κάθε φορά ένα ολόκληρο object μόνο για ένα single call; (Ερώτηση είναι, πραγματικά, οχι κριτική). Εκτός βέβαια και αν κινείσαι με βάση την πρόβλεψη οτι θα σου επιτρέψει αυτή η υλοποίηση να προσαρμοστείς και σε πιό σκληρά σενάρια (com+, remoting και δεν συμμαζεύεται). Γενικά, τι σε ώθησε να χρησιμοποιήσεις instances για αυτή τη λειτουργία;

Σωστές ερωτήσεις! Ομολογώ με προβλημάτισαν για λίγο! Η αλήθεια είναι ότι έχω πιο σκληρά σενάρια (client/server web services), αλλά και σε αυτή την περίπτωση θα μπορούσα να έχω shared methods. Επειδή όμως ο εν λόγω manager διαχειρίζεται όλα αυτά τα layers (data change loging, event loging, permission control, relationship management, sql generator) ήθελαν να έχω πρόσβαση σε κάποια από αυτά με τη μορφή properties, διαφορετικά θα είχα πολύπλοκα method signatures. Τώρα καλώ myManager.Update(myQuery, myData), διαφορετικά θα έπρεπε να έχω πολλά overloads.
Π.χ. δεν θέλω να γίνει έλεγχος δικαιωμάτων στην περίπτωση μιας εσωτερικής διαδικασίας που κάνει ο application server (web services), ή δεν θέλω να γίνεται data loging στην περίπτωση αποθήκευσης μεγάλο όγκου δεδομένων (θα καθυστερούσε πολύ η διαδικασία. στην περίπτωση αυτή κάνω data loging με άλλο τρόπο).
Δίνει επίσης την ευκαιρία, μια που έχει ένα δικό της connection με την βάση, να εκτελέσω δυο update πολύπλοκων αντικειμένων σε ένα db transaction. Το connection κλείνει στο dispose της κλάσης (using myManager and new manager .......... end using)
Οπότε με όλα αυτά τα πλεονεκτήματα που μου δίνει η κλάση αυτή θεωρώ ότι η δημιουργία νέων instances κάθε φορά που την θέλω δεν αποτελεί μειονέκτημα.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Γεια σας.

Συνεχίζω από εκεί που έμεινα με βάση της ερωτήσεις του Σωτήρη (cap) :

-------------------------------------------------------------------------------------------------------------

Μερικές ερωτήσεις επάνω σε αυτό:

Ο manager σου αναλαμβάνει να διαχειριστει και τυχόν collections του object που διαχειρίζεται;

Επίσης, ο manager είναι ένας, πολλοί, shared ή instance;

Πώς δημιουργείς με αυτή την προσέγγιση ένα νέο, άδειο object;

-------------------------------------------------------------------------------------------------------------

Όχι, ο Manager ή Managers που έχω δεν διαχειρίζονται collection των objects μου. Για αυτό υπεύθυνα είναι τα ίδια τα identities.

Έχω πολλούς Managers π.χ DBManager ο οποίος επικοινωνεί με το DAL. Άρα οποιοδήποτε object θέλει να κάνει κάτι στην βάση θα περάσει μέσα από εκεί. Έχω ExportManager, όπου μέσα από εδώ στέλνω τα objects τα οποία θέλουμε να εκτυπώσουμε, να μετατρέψουμε σε XML και γενικά οτιδήποτε έχει να κάνει με αποστολή δεδομένων έξω από την εφαρμογή μου. Φυσικά έχω και τον αντίστοιχο Import.

Τώρα τελευταία θέλω να προσθέσω μία νέα λειτουργία στις εφαρμογές μου χρησιμοποιώντας MSMQ. Μπορείτε να δείτε πόσο εύκολα μπορεί να γίνει αυτό;

Όλοι οι Managers είναι Singleton, προς το παρών. Όχι γιατί δεν θα μπορούσαν να γίνουν multiinstance αλλά προτιμώ να δουλεύω με Singleton.

H δημιουργία για ένα νέο άδειο object είναι δουλειά του Manager. Όπως ανέφερα ένα object δεν θα πρέπει να γνωρίζει το περιβάλλον και τις απαιτήσεις μέσα στο οποίο δουλεύει, θα πρέπει να γνωρίζει όμως βασικά πράγματα έτσι ώστε να δώσει οδηγίες στους Managers για το πως θα γίνει μία ενέργεια πάνω σε αυτό.

Οπότε στων κώδικά μου δεν υπάρχει το

Dim myCustomer as New Customer , αλλά

Dim myCustomer as Customer

myCustomer=myGeneralCollection.Create(AppObj.Customer)

myCustomer.LastName="Parissis"

myCustomer.FirstName="George"

myDBManager.Save(myCustomer)

Εδώ κάποιος θα μου πει. Ωραία και αν έγραφα Dim myCustomer as new Customer ποιο θα ήταν το πρόβλημα... Κανένα θα έλεγα. Σε αυτήν την φάση. Αν όμως πάμε λίγο πίσω στην κεντρική φράση "Κανένα object δεν θα πρέπει να γνωρίζει το περιβάλλον και τις απαιτήσεις απαιτήσεις, μέσα στο οποίο τρέχει" θα δούμε ότι ο κώδικας που έγραψα έχει σχέση με αυτό. Πολλές φορές ακόμα και στην ίδια την εφαρμογή, φανταστείτε πόσο μάλλον σε διαφορετικές, οι οποίες έχουν πουληθεί σε διαφορετικές γεωγραφικές περιοχές στην Ελλάδα ο χρήστης ίσως να θέλει να έχει διαφορετικές default τιμές στην δημιουργία κάποιων objects. Άρα το περιβάλλον τις εφαρμογής έχει μία απαίτηση. Δηλαδή όταν περνάω έναν νεο πελάτη και είμαι στην Αθηνα στην Πόλη να μου περνάει σαν default Αθήνα. Αυτό δεν είναι δουλειά του object να το γνωρίζει αλλά είναι πληροφορία που έχει να κάνει με την εφαρμογή και με τις ιδιαιτερότητες του χρήστη. Φυσικά ένα απλό παράδειγμα έφερα, μπορείτε να φανταστείτε πως μπορούν να επεκταθούν οι απαιτήσεις των χρηστών και σε άλλα πράγματα...

Όσο για Dataset που ανέφερε ο Δημήτρης (papadi). Μπορεί να χρησιμοποιηθεί και αυτό αλλά εγώ δεν το προτιμώ. Χρησιμοποιώ DataBinding σε όλες τις εφαρμογές και λίστες αλλά Dataset που θα ήταν και η φυσική επιλογή όχι. Οι λόγοι είναι δύο :

Resources... Είμαι απογοητευμένος μπορώ να πω... BindingList ανώτερο θα έλεγα.

Δεν ταιριάζει με την φιλοφοφία του OOP (αφού μιλάμε για OOP). Καλά εδώ θα μου πείτε, έλα ρε Γιώργο είναι λόγος τώρα αυτός;... Όχι και έχετε δίκιο... τι να κάνω όμως είμαι ψείρας...

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

[ ... είμαι σε άδεια, και τριγύρναγα σαν το τουριστάκι την Αθήνα με το Μετρό για αλλαγή, και έχασα αυτό το thread απ'την αρχή ... προσπαθώ να catch up όμως :P ]

Πρώτα να πώ ότι έχοντας στο παρελθόν αναγκαστεί να γράψω πολλές "GetByXXX" μεθόδους τόσο σε Managers όσο και σε "ημι-εξυπνα" Data Transfer Objects - τα οποία πολλοί θεωρούσαν Business Objects λόγω ενός υποτυπώδους validation και 3-4 rules, ΜΙΣΩ πλέον αυτό το approach. Πολύ copy - paste inheritance ρε παιδιά, brain-dead εργασία.

Επίης θεωρώ οτι τα typed datasets δεν είναι και τόσο "αισχρά" όσο πιστεύουν πολλοί. Σε ένα generic approach σαν αυτό που περιέγραψε ο Πάνος, τα typed datasets θα μπορούσαν κάλλιστα να είναι ο mapper, γι' αυτό φτιάχτηκαν άλλωστε.

Στη δουλειά τώρα. Μάλλον είμαστε τυχεροί σε αυτή την εταιρία, γιατί έχουν περάσει κατα καιρούς αρκετοί έξυπνοι άνθρωποι, ένας εκ των οποίων ο Μάριος Μαργαρίτης. Πολλοί απο εμάς - κι εγώ δεν τον πρόλαβα live στην εταιρία  - τον έχουν δεί σε κάποιο DevDay πέρυσι να μιλαέι για DataAccess, έχοντας σαν παράδειγμα ένα DAL βασισμένο σε Typed Datasets. Αυτό, έχει δεν έχει περιορισμούς, το "κληρονομήσαμε" στη δουλειά, και είναι η αλήθεια οτι μας έχει βολέψει. DataSet persistence με μια γραμμή κώδικα.

Θεωρώ λοιπόν το typed dataset ως mapper και data transfer object μαζί. Επίσης, μου δίνει και πάμπολλα utilities όπως calculated πεδία, filtering, HasChanges (!!! ΠΟΛΥ ΣΗΜΑΝΤΙΚΟ !!!), και διάφορα άλλα μικρά καλούδια.

So far λοιπόν, έχω retrieval / persistence ( οκ, retrieval με πολύ basic criteria για τώρα, βάσει PKeys & relations στο DataSet, αλλά το συζητάμε μετά αυτό ), σε κάποια DTOs, σχεδόν automagically.

Τώρα, τα business objects. Μεγάλο κεφάλαιο. Αν πιστέψεις το φίλο μας το CSLA, to Customer είναι ένα business object. Κατα συνέπεια, στην περιγραφή του σεναρίου σου, τα ουσιαστικά μεταφράζονται σε "business objects". Διαφωνώ. Τα business objects θα έπρεπε να είναι πολύ πιο coarse grained - "μεγαλύτερα" αντικείμενα, τα οποία χρησιμοποιούν τα data transfer objects για να κάνουν τη δουλειά τους.

Στη δικιά μας δουλειά, ένα τέτοιο business object - ActivityDataSources τα λέμε εμείς - χρησιμοποιεί κατα μέσο όρο 4-5 typed datasets, τα οποία γίνονται load on demand όταν χρειάζονται, γίνονται persist μόνο όταν έχουν αλλαγές, και σύντομα θα γίνονται cached & discarded όταν πλέον δεν τα χρειάζεται κανείς.  Όλα αυτά βάσει ενός generic manager μηχανισμού, όχι πολύ διαφορετικού απο αυτόν που προτείνει ο Παναγιώτης στην πρώτη σελίδα.  ( Τύποις generic, γιατί είμαστε ακόμη παγιδευμένοι σε 1.1, αλλά μόλις "ροκανίσαμε" την πρώτη μπάρα στο παράθυρο !!! :D  )

Τώρα στο άμεσο μέλλον, θα ήθελα πολύ να λύσω δύο "προβλήματα".

1. Fill τα typed datasets μου, όχι μόνο βάσει primary keys & relations, αλλά με πιο σύνθετα κριτήρια.
2. Να είμαι Persistence Medium Agnostic. Γιατί να ξέρω ΠΟΥ σώζονται αυτά που σώζωνται;

Αυτά τα δύο σκοπεύω να τα λύσω "μπλέκοντας" το DAL που κληρονομήσαμε απο το Μάριο, με το δικό μου, το πρώτο μου post σε αυτό το site πριν 1-μισι χρόνο, στο οποίο χρησιμοποιώ external configuration files για να ορίσω "data actions" τα οποία η εφαρμογή μου καλεί by name, και μου δίνουν κι αυτά μετά διάφορα καλούδια, κυρίως όμως caching, parameter validation & persistence medium adaptability.

Τελειώνοντας, να πώ οτι το Object Orientation , και γενικότερα η πληροφορική, είναι σαν πλαστελίνη. Δεν είναι "σκληρή επιφάνεια", μας δίνει ένα βασικό set of rules - mentallity καλύτερα, κι απο 'κεί και μετά είμαστε υποχρεωμένοι να "εξελιχθούμε" σε .. fluid καταστάσεις. Δε χρειάζεται τα ουσιαστικά στην πρόταση να είναι ντε και καλά objects, στην πραγματική ζωή. Αυτό ήταν και το βασικό misconception στους Java/EJB developers που τελικά κατάφερναν να κάνουν γαιδούρια να αγκωμαχάνε απο το βάρος ... 4 objects.

Καλή φάση η άδεια, ακόμα και αν είναι μόλις 3 μέρες !!!

Υ.Γ. Όλα τα παραπάνω, δεν αναιρούν την αμέριστη εκτίμησή μου στο O/R mapping, και αφορούν δεδομένα και objects τα οποία αναφέρονται directly σε "problem domain data" στη βάση δεδομένων μου. Όσον αφορά workflow & ui generation, όπου τα objects μου είναι by definition "έξυπνα", θα χρησιμοποιούσα O/R mapping χωρίς δεύτερη σκέψη. Βλέπετε, απο λύση σε λύση κι απο project  σε project  το structure αυτών των αντικειμένων δεν αλλάζει και τόσο συχνά. Απο την άλλη, η βάση ή καλύτερα το view του σχήματος της βάσης το οποίο καλείται να χρησιμοποιήσει η εφαρμογή για μια νέα λύση για πελάτη αλλάζει σχεδόν κάθε μήνα, με κάθε νέο project. Εκεί δε σε παίρνει να ξαναγράφεις κώδικα κάθε τόσο.

---

Angel
O:]

  Γειά σας παιδιά.

  Είμαι ένας από τους πολούς που προσπαθούν να μάθουν να γράφουν N-TIER εφαρμογές σε VB.NET. Έχουν πέσει στα χέρια μου κάποια βιβλία τα οποία αναπτύσουν μία εφαρμογή και ταυτόχρονα προσπαθούν να σου μάθουν πως γίνετε αυτό. Φαίνετε όμως ότι έχω κάποια κενά και δεν μπορώ να καταλάβω πως μπορώ να ολοκληρώσω τα παραδείγματα αυτά σύμφωνα με τον τρόπο που θέλω να γίνονται οι καταχωρήσεις, πχ όχι μία-μία αλλά όλες μαζί (όπως κάνουμε με ένα Dataset). Έχω ξαναθέσει την ερώτηση αυτή αλλά απάντηση δεν πήρα, για να είμε ακριβής πήρα μιά απάντηση από τον KELMAN. Από την απάντησή του αλλά και από τις μη απαντήσεις των υπολοίπων καταλαβαίνω ότι ζητάω κάτι δύσκολο που μπορεί να γίνει μέσω του forum. Δεν ξέρω ίσως ζητάω πολλά, αλλά αν υπάρχει κάποιος άλλος τρόπος πχ μέσω email και κάποιος έχει το χρόνο να το κάνει θα του ήμουν υπόχρεως.

 

  Thanks

Προσπάθησε να διατυπώσεις ακριβώς αυτό που θέλεις να κάνεις σε ένα νέο thread και βλέπουμε.

Ποια είναι ακριβώς η ερώτηση; 

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Ο Δημήτρης έχει δίκιο. Κολλώντας μία ασαφή ερώτηση σου σε ένα thread που έχει ουσιαστικά κλείσει, οι πιθανότητες να πάρεις απάντηση είναι ελάχιστες. Όσον αφορά την αρχική σου ερώτηση, δεν είναι δύσκολη, αλλά υπερβολικά ασαφής. Ποιές καταχωρήσεις θέλεις να γίνονται μαζί? Τί εννοείς να γίνονται μαζί? Τί εννοείς καταχωρήσεις? Χρησιμοποιείς κλάσεις, datasets, τί? Παραδείγματα βιβλίου?

Από τη στιγμή που έχεις ήδη τα βιβλία και αν το πρόβλημα σου είναι να καταλάβεις τα παραδείγματα, θα πρότεινα απλά να τα προσέξεις περισσότερο. Μήπως έχεις φτιάξει μία εικόνα στο μυαλό σου και προσπαθείς να ταιριάξεις το βιβλίο σε αυτή? Η ανάπτυξη n-Tier εφαρμογών διαφέρει αρκετά από την ανάπτυξη απλών φορμών. Θα πρέπει εσύ να προσαρμοστείς σε όσα σου λέει το βιβλίο, όχι να προσαρμόσεις το βιβλίο σε όσα νομίζεις.
Τα παραδείγματα των βιβλίων είναι πάντα απλοποιημένα. Αν δεν μπορείς να τα καταλάβεις, θα έχεις μεγάλο πρόβλημα στην ανάπτυξη μίας εφαρμογής. Επιπλέον, όπως σου είπε και ο Kelman, κανένα βιβλίο δεν μπορεί να καλύψει τα πάντα. Θα πρέπει να διαβάσεις και το MSDN, το οποίο καλύπτει σχεδόν κάθε τομέα.

Ίσως τέλος απλά να χρειάζεσαι πιο βασικά πράγματα από το πως να φτιάξεις μία N-TIER εφαρμογή. Η ερώτηση που έκανες δεν έχει τίποτε να κάνει με N-tier, αν και δεν κατάλαβα ακριβώς τι εννοείς. Προσπαθείς να αποθηκεύσεις αντικείμενα? Πίνακες? Τί? Μήπως πρέπει να ξεκινήσεις με ένα εισαγωγικό βιβλίο για VB.NET πριν περάσεις σε N-tier?

Όσο κάνεις τόσο ασαφής ερωτήσεις, απάντηση δεν θα παίρνεις. Στο εξήγησε και ο Kelman, σπάνια υπάρχει χρόνος για να απαντήσει κανείς σε ασαφής ερωτήσεις. Μία συγκεκριμένη ερώτηση συνήθως παίρνει απάντηση σε λιγότερο από 1 ώρα. Μία γενική ερώτηση μπορεί να χαθεί. Μία ασαφής ερώτηση μάλλον δεν θα πάρει απάντηση.

---

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