Design & Architecture

Re: data utils sample project download

anjelinio — Thu, 30 Jun 2005 19:21:42 GMT

Καλημέρα. Μόλις ανέβασα ένα sample project του API, εδώ.

Re: data utils download & μικρό tutorial

anjelinio — Wed, 29 Jun 2005 22:48:48 GMT

Ακριβώς το αντίθετο συμβαίνει. Επειδή ΔΕΝ διάλεξα το Application Configuration σαν storage για τα paths, αναγκάστηκα να κάνω τα Singletons .. semi-Singletons

Βασικά, ήθελα να μπορώ να κάνω init απο ένα οποιοδήποτε xml stream, οπότε ... ήταν pointless να κρατήσω οποιοδήποτε value στο app. config, τη στιγμή που δε θέλω να ξέρω τι είδους stream διαβάζω ...

Σύντομα θα ανεβάσω και κάποιο(α) sample project(s), αυτό που έχω ήδη δυστυχώς ήταν internal, και έχει ακόμη πράγματα που θα με βάραγαν απ'την εταιρία αν ανακάλυπταν οτι τα δείχνω απ'έξω

Αυτός είναι και ο λόγος που δεν υπάρχει το source μέσα στο .rar, αλλά σκοπεύω να ψήσω τον κόσμο εδώ οτι τελικά .. είναι καλό publicity να δίνεις κώδικα στον κόσμο free. Μόλις τα καταφέρω, θα ανεβάσω όλον τον κώδικα στο site.

Re: data utils download & μικρό tutorial

KelMan — Wed, 29 Jun 2005 22:38:12 GMT

Έριξα μια ματιά στο walkthrough σου... Το διάβασα στα πεταχτά και δεν έχω προλάβει να παίξω με τα dlls αλλά μου έκανε εντύπωση αυτό που έγραψες για τα singletons που δεν είναι singletons και ότι οφείλεται στο Application Configuration που διάλεξες ως init storage. Μιας και δεν δίνεις παραπάνω πληροφορίες, έχει να κάνει το πρόβλημα με το ότι το App.config γίνεται p*** κατά το loading του assembly;
Επίσης, αν μας έδεινες και ένα μικρό project για demo, μιας και μπήκες στον κόπο να γράψεις όλο αυτό το walkthrough, θα ήταν καλύτερα... Να τολμήσω να ζητήσω να μας έδειχνες και λίγο κώδικα από τα DLLs, ας πούμε τα highlights;

data utils download & μικρό tutorial

anjelinio — Wed, 29 Jun 2005 19:31:22 GMT

Καλημέρα παιδιά. Όπως είπα, μόλις έγραψα ένα μικρό (πολύ μικρό) walkthrough του API που περιέγραψα στα παραπάνω posts, κι έβαλα τα dlls σε ένα .rar για download.

Αν θέλετε, μπορείτε να τα βρείτε εδώ

Re: Μια άποψη για ένα data layer ...

anjelinio — Mon, 27 Jun 2005 17:29:12 GMT

Καλημέρα παιδιά, καλή εβδομάδα, ελπίζω να σας βρήκε όσο μαυρισμένο με βρίσκει κι εμένα

Νομίζω οτι κάπου δεν πέρασα καλά τους στόχους μου. Ο βασικός στόχος είναι να κερδίσω (εγώ και η ομάδα) χρόνο υλοποίησης, χωρίς να θυσιάσω performance και "ποιότητα" κώδικα. Επίσης, μεγάλο μέρος όλης αυτής της ιστορίας έχει να κάνει με ευελιξία και εύκολη διαχείρηση.

Οπότε, απαντώ σε μερικά θέματα που αναφέρθηκαν στα 2 τελευταία posts.

Ναί, πρέπει να περνάς το object[] σε κάθε κλήση, αλλά με τον "παραδοσιακό" τρόπο με Commands, πάλι δεν περνάς παραμέτρους, και μάλιστα με πολύ περισσότερες γραμμές κώδικα; (Αυtό ισχύει και για το Data Access Block φυσικά ... )

Το xml file δεν είναι και τόσο μεγάλο liability, υπάρχουν τρόποι να διασφαλίσεις το integrity του, απο τα permissions στα Windows ως signing το αρχείο με ένα digital signature, κι όλα τα μεταξύ των 2 ... όταν πλέον μιλάς για αλλαγές απο κάποιον ο οποίος έχει admin access στο σύστημα, είναι περιττό να πείραξει καν τα config files μου .. he owns me!!! ( καλά .. βαριά κουβέντα είπα, αλλά καταλαβαίνετε το πνεύμα του αστείου .. )

Ερχόμαι απ'τη μεριά της Java στο .NET, οπότε ναι, έχω μια εκτίμηση στα O/R εργαλεία. Αλλά εκτός κι αν χρειάζεσαι το Object Orientation (υπάρχει κάποιο business logic κάποιας σοβαρότητας ) ... είναι μάταιο, και φτάνει να γίνεται overhead. Σκέψου την περίπτωση όπου ένα query θα μου γυρίσει 12000 value objects *-} ... εδώ θα πείς "οκ, σε αυτήν την περίπτωση μη χρησιμοποιήσεις τον O/R mapper" - αλλά τότε έχω 2 τρόπους να μιλώ στα data sources μου, χάνω την ομοιογένεια του κώδικά μου, κτλ κτλ

Η περίπτωση του custom data layer κάτω απο COM+ ... είναι ο λόγος για τον οποίο έγραψα αυτό το block ... για να μη χρειαστεί ποτέ ξανά για ν'αλλάξω μια παράμετρο να κάνω rebuild & redeploy, στο δικό μου μηχάνημα καί στο live server. 1 λεπτό να γράψεις την αλλαγή, και 40 λεπτά να την εγκαταστήσεις ... έχω ένα COM+ wrapper τριγύρω απ'το API μου, κι έχω τα best of both worlds.

Τέλος, το API δε γυρίζει μόνο data sets ... θα ήταν πολύ .. gay .. εκ μέρους μου πιστέυω Οπότε, γυρίζει datasets, readers, xml κι ένα δικό μου type, το ResultSet, το οποίο μοιάζει περισσότερο με το παλιό Recordset του ADO, και κάνει paging χρησιμοποιώντας εσωτερικά readers.

Τι άλλο, τι άλλο ... ε, σα "σούμα" έχω όλα τα παραπάνω, πολύ λιγότερο κώδικα, caching, paging , parameter validation ... δε νομίζω οτι θα τ' άλλαζα εύκολα όλα αυτά για το data access block, σίγουρα όχι για ένα custom COM+ layer με Commands κτλ κτλ, και μόνο αν χρειάζεται απόλυτα για έναν O/R mapper σαν το NHibrnate.

Σε λίγες μέρες θα βγάλω το dll κι ένα sample project στα downloads αν μπορώ, για να πάρετε και μια γεύση απο πρώτο χέρι

Πολύ καλή εβδομάδα μας

Re: Μια άποψη για ένα data layer ...

George J. Capnias — Sat, 25 Jun 2005 19:59:31 GMT

Εκτός από την αυτά που είπε ο Άρης, και είναι η πλήρες ανάπτυξη των δυνατοτήτων που υπάρχουν κάτω από .NET, ίσως θα μπορούσες να δοκιμάσεις κάτι πιο απλό:

To SQLXML .NET Support. Δεν ξέρω έτσι που τα περιέγραψες, ήταν σαν να μου έλεγες για αυτό. Τα diffgrams είναι XML αρχεία που μπορούν να κάνουν SELECT, UPDATE, DELETE, INSERT, να αποθηκευτούν κεντρικά κάτω από ένα directory του IIS και να τα χρησιμοποιούνται. Μπορούν να δέχονται παραμέτρους, να χρησιμοποιούν stored procedures... Μπορούν να γίνουν SELECT με βάση ένα XSD schema...

Υπάρχει υποστήριξη από το .NET Framework, και δεν είναι τόσο φοβερό στην χρήση...

George J.

Re: Μια άποψη για ένα data layer ...

Aris — Sat, 25 Jun 2005 05:23:43 GMT

Όπως φαίνεται (με διορθώνεις εάν κάνω λάθος), οι στόχοι σου είναι:
- να περιγράψεις το σύνολο των εργασιών στην βάση δεδομένων με ένα σύνολο δηλώσεων (σε XML), και να παράγεις δυναμικά (κατά τον χρόνο εκτέλεσης) τα ακριβή SQL statements που χρειάζεσαι, έχοντας σταθερό τον κώδικα αυτό (δηλαδή τον κώδικα που "εκτελεί" τις δηλώσεις). Αυτό οδηγεί στην ανάγκη να υπάρχει το object[] που περνάς σαν παράμετρο στο παράδειγμα που δίνεις.
- να έχεις την δυνατότητα αλλαγής βάσης δεδομένων, αλλάζοντας τις δηλώσεις (στο σημείο περί αλλαγής datasource provider, είσαι κάπως ασαφής. Ο μηχανισμός, υποθέτω είναι επεκτάσιμος. Δημιουργείς όμως ODBC driver για τις άλλες πηγές δεδομένων, ώστε να έχεις SQL σύνταξη;
- να συγκεντρώσεις όλο τον κώδικα πρόσβασης στα δεδομένα σε ένα σημείο (ουσιαστικά ένα code.dll και ένα declarations.xml). Όμως, το xml αρχείο συνοδεύει την εφαρμογή και είναι αλλοιώσιμο, κάτι που αποτελεί (κατ' αρχήν) πρόβλημα ασφάλειας.

Κατά την γνώμη μου, θα πρέπει να δείς:
- Το Data Access Application Block. Συνεργάζεται με διάφορες σχεσιακές βάσεις δεδομένων και διευκολύνει την χρήση SQL statements και stored procedures
- Εργαλεία Object/Relational Mapping (ORM). Δες αυτή την συζήτηση στο www.theserverside.net για μιά καλή λίστα. Αυτά σου επιτρέπει μιά αντικειμενοστραφή θεώρηση των δεδομένων

Επίσης, θα πρότεινα να εξετάσεις την περίπτωση να γράφεις ένα ειδικό data access layer component ανά εφαρμογή.
Αυτό θα μπορούσε να υλοποιηθεί σαν ServicedComponent (εάν θέλεις να μπεί στο COM+) ή σαν MarshalByRefComponent/ContextBoundObject και να εμφανίζεται (μέσω .Net remoting) από ένα windows service.

Στην περίπτωση αυτή, δεν είσαι καν υποχρεωμένος να επιστρέφεις datasets (αλλά απλούστερες δομές [DataTransferObjects - DTOs] που είναι σαφώς ελαφρύτερα. Έχεις και την δυνατότητα του binary serialization...
Τέλος, εάν η ανάγκη γιά αλλαγή μέσου αποθήκευσης (σχεσιακή βάση, αρχεία XML κλπ) είναι επιτακτική, γράφεις ένα facade, συνδυασμένο με ένα factory...

Άρης

Μια άποψη για ένα data layer ...

anjelinio — Fri, 24 Jun 2005 20:43:31 GMT

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

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

Η βασική ιδέα είναι η δυνατότητα για declarative definition όλων των data queries, καθώς και των data sources. Aυτά σε xml ( duh ... trendy boy ), σε ένα σχήμα κάπως έτσι:

<data-action id="SelectCount" type="0" data-source="local" query="select count(*) from ? where ?=0" cached="false"

cache-timeout="0">

</params>

</data-action>

... και ...

<data-action id="GetSystemAttributes" type="1" data-source="local" query="sp_GetSysAttrValuesByAttrType" cached="true"

cache-timeout="3600000">

</params>

</data-action>

Στο programmatic μέρος της ιστορίας, όλα αυτά διαχειρίζονται απο 2 Singletons, ένα για τα data sources κι ένα για τα data queries. Όλο το initialization γίνεται σε 2 γραμμές κώδικα, και κάθε call είναι άλλη μια γραμμή:

FileStream io_in_ds = new FileStream(strXmlDSourcesPath, FileMode.Open, FileAccess.ReadWrite);

DataSourceManager.NewInstance(io_in_ds);

FileStream io_in = new FileStream(strXmlActionsPath, FileMode.Open, FileAccess.ReadWrite);

DataActionManager.NewInstance(io_in);

DataSet ds = DataActionManager.GetInstance().ExecuteQuery("GetSystemAttributes",

new object[] {pid});

Το βασικό "πλεονέκτημα" που κυνήγησα σε αυτό το approach, ήταν οτι βάζω τον data access κώδικά μου σε ένα και μοναδικό σημείο, κι έτσι κερδίζω στα κάτωθι:

Όταν ο κώδικας δεν είναι διάσπαρτος και γραμμένος απο διακόσιους ανθρώπους, έχεις πολύ καλύτερο έλεγχο στην ποιότητά του. Μπορείς ας πούμε να διασφαλίσεις οτι τα πάντα θα εκτελεστούν σαν prepared statements, οτι τα connections θα ελευθερωθούν πίσω στο pool, κτλ κτλ

Έχοντας ένα single entry-point στο data access, μπορείς να κάνεις πράγματα όπως parameter validation & caching πολύ πιο εύκολα.

Δίνοντας ένα απλό interface στον προγραμματιστή, κι ένα εξ' ίσου απλό xml schema στον DB-guy, χωρίζεις τα responsibilities. Εγώ, σαν κωδικογράφος, δε χρειάζεται να ξέρω πως έχει γράψει ο άλλος τη βάση απο κάτω. Θέλω να ξέρω ένα τύποις interface μόνο, του στύλ "αυτό το query, μ'αυτό το όνομα κι αυτές τις παραμέτρους θα σου επιστρέψει αυτό κι αυτό". Τι με νοιάζει αν έιναι stored procedure, κάποιο direct query ή οτιδήποτε άλλο. Επίσης, σαν DB-guy, κάνω τη δουλειά μου, ορίζω ένα interface στην xml, manage-άρω εγώ τα connection strings ... transparently απ'την υπόλοιπη ομάδα, οι οποίοι .. δε χρειάζεται να ξέρουν ( encapsulation ?? )

Επίσης, αυτο το declarative επιτρέπει transparent αλλαγές, χωρίς re-compile. Αν αλλάξω data source απο Access σε SQL Server ... δε χρειάζεται να κάνω καμμία αλλαγή σε κώδικα, ούτε καν start-stop τον IIS σε περίπτωση ενός web app. Αν θέλω ν'αλλαξω cache settings .. piece of cake .. τελος πάντων, είναι πολύ πιο ευέλικτο paradigm.

Τέλος, έχοντας ένα μηχανισμό όπου κάθε data source έχει και έναν provider (ορισμένος στην xml, κλασσικά .. ), μπορώ να χρησιμοποιώ το ίδιο interface για queries σε μη-παραδοσιακές data sources, όπως flat files, xml, το Arc IMS (!!!) κτλ κτλ κτλ ...

Άντε .. πολλά είπα ε; Αν έχει κάποιος κάποια δεύτερη γνώμη να μοιραστεί ... θα χαρώ πολύ να συζητήσουμε το θέμα

Πολύ καλή μέρα μας