Πρώτα Βήματα - Αρχές προγραμματισμού

Απ: OOP και Database

miket969 — Tue, 09 Jun 2009 19:24:10 GMT

Σιγουρα ο Παναγιώτης έχει δίκιο σε αυτό που λέει... Όταν μπαίνει στη μέση το θέμα του scalability είναι προτιμότερο να αλλάζεις απλά ένα SQL Query και η κλάση σου να διαχειρίζεται το αποτέλεσμα πιο generically (σαν ContactInfo ας πούμε στο παράδειγμά του). Για να διορθώσω το σκεπτικό μου στην προηγούμενή μου απάντηση (ακόμα πιστεύω ότι το θέμα είναι υποκειμενικό): ακόμα καλύτερο δε θα ήταν μια κλάση να αναπαριστά τα tables της βάσης (properties: table_name, columns..., methods: getData(), clearTable()...) και να δημιουργούμε instances αυτής στο πρόγραμμα για κάθε table? Και αν θέλουμε και κάτι παραπάνω για ένα table (μια παραπάνω μέθοδο, property) να την κάνουμε inherit? Και η προσαρμογή ενός καινούριου contact δε θα είναι πιο εύκολη?

Απ: OOP και Database

panagiotis_georgiadis — Fri, 05 Jun 2009 23:29:01 GMT

miket969:
Καλησπέρα φίλε,
Εγώ δε μπορώ να ισχυριστώ ότι έχω ΠΟΛΛΗ περισσότερη εμπειρία από σένα (μολις ξεκίνησα να ασκώ το hobby μου επαγγελματικά ) αλλά η γνώμη μου πάνω στο θέμα που θίγεις είναι ότι είναι τελέιως υποκειμενικό. Για να γίνω πιο συγκεκριμένος
1. Μπορεί να ισχύει, μπορεί και όχι, ανάλογα το design που έχεις κάνει για την εφαρμογή σου.
2. Σίγουρα βολεύει να είναι ίδιοι σαν δομή, είναι πολύ βολικό για να αναπαριστάς τα δεδομένα της βάσης μέσα στην εφαρμογή σου, αλλά αυτό δε σε εμποδίζει να βάλεις ένα-δύο properties ή μεθόδους παραπάνω στην κλάση σου.
3. Και τέλος μπορείς (αν σε βολεύει στην εφαρμογή σου) να μη μοιάζει καθόλου η κλάση με τον πίνακα της βάσης, αλλά να παίρνει μόνο τα δεδομένα που θέλει από ένα πολύπλοκο query (που θα περιέχει πολλούς πίνακες, join δεξια κ αριστερά) και να κάνει τη δουλειά της.

Από όσες υλοποιήσεις εφαρμογών έχω δει μέχρι τώρα που χρησιμοποιούν βάσεις δεδομένων, μπορώ να πώ ότι το να φτιάχνεις κλάσεις που καθρεπτίζουν ένα πίνακα και τα δεδομένα του είναι πολύ πιο βολικό και οδηγεί σε "καθαρότερο" κώδικα, όπου μπορείς να καταλάβεις πιο εύκολα από πού και πώς ήρθε τι (πιο εύκολο debugging ). Όσο μεγαλύτερο το project, τόσο πιο σημαντικό είναι αυτό...

Σίγουρα μπορεί να ισχύει κάτι τέτοι ή όχι. Αν το design που έχεις κάνει είναι χάλια μάλλον θα ισχύει. Αν θες να κάνεις κάτι που να αξίζει να λέγεται πραγματικό design τότε δεν έχει και πολύ σχέση ο κώδικας της εφαρμογής σου (=client) με τη βάση δεδομένων (=server). Θυμάμαι στο παρελθόν να έχω δουλέψει με εργαλείο αυτοματοποίησης που κάνει export ένα database schema (τη δομή της database) σε κώδικα, ώστε να δημιουργεί π.χ. μια κλάση ανά πίνακα. Σκεφτείτε όμως την αξία της όλης εφαρμογής στο χρόνο και την επεκτασιμότητα με το εξής παράδειγμα:

Έστω ότι έχω μια βάση δεδομένων που λέγεται Agenda, στην οποία καταχωρείται ο κατάλογος ονομάτων σε ένα Table TBL_CONTACTS. Αρχίζω τώρα να το σχεδιάζω:

+-----------+--------------------+-----------------------------+-----------------+----------------------------+
[ ID        | FirstName         | LastName                   | Telephone      | Address                   |
+-----------+--------------------+-----------------------------+-----------------+----------------------------+
[ 001      |   Kostas           | Kostantinou                 | ...            | ...                        |
+-----------+--------------------+-----------------------------+-----------------+----------------------------+
|...                                                                                                          |
+-----------+--------------------+-----------------------------+-----------------+----------------------------+

Αν πάω με την μία λύση, η εφαρμογή μου που λέγεται MyAgendaApp θα έχει μια κλάση ως εξής:

public class TableContacts
{
    private int m_ID;
    private string m_strFirstName;
    private string m_strLastName;
    private string m_strTelephone;
    private string m_strAddress;

    //...
    public void GetContacts()
    {
        //...
    }
}

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

Με την παραπάνω λύση, θα προσθέσω (ούτως ή άλλως) ένα ακόμα πεδίο στον Πίνακα της βάσης. Το μεγάλο πρόβλημα γεννιέται όταν πρέπει να αλλάξω για τον ίδιο σκοπό και την κλάση προσθέτωντας ακόμα ένα μέλος, και πιθανότατα αλλάζοντας την GetContacts() σε GetContacts(string CityName). Φανταστείτε το χαμό αν η εφαρμογή είναι μερικές 100άδες κλάσεις και ισάριθμα αρχεία.

... και πόσο πιο εύκολα μανατζάρονται τέτοια θέματα με SQL Queries (γι'αυτό υπάρχουν άλλωστε). Σας αφήνω να σκεφτείτε τις εναλλακτικές λύσεις...

Απ: OOP και Database

miket969 — Fri, 05 Jun 2009 21:46:37 GMT

Καλησπέρα φίλε,
Εγώ δε μπορώ να ισχυριστώ ότι έχω ΠΟΛΛΗ περισσότερη εμπειρία από σένα (μολις ξεκίνησα να ασκώ το hobby μου επαγγελματικά ) αλλά η γνώμη μου πάνω στο θέμα που θίγεις είναι ότι είναι τελέιως υποκειμενικό. Για να γίνω πιο συγκεκριμένος
1. Μπορεί να ισχύει, μπορεί και όχι, ανάλογα το design που έχεις κάνει για την εφαρμογή σου.
2. Σίγουρα βολεύει να είναι ίδιοι σαν δομή, είναι πολύ βολικό για να αναπαριστάς τα δεδομένα της βάσης μέσα στην εφαρμογή σου, αλλά αυτό δε σε εμποδίζει να βάλεις ένα-δύο properties ή μεθόδους παραπάνω στην κλάση σου.
3. Και τέλος μπορείς (αν σε βολεύει στην εφαρμογή σου) να μη μοιάζει καθόλου η κλάση με τον πίνακα της βάσης, αλλά να παίρνει μόνο τα δεδομένα που θέλει από ένα πολύπλοκο query (που θα περιέχει πολλούς πίνακες, join δεξια κ αριστερά) και να κάνει τη δουλειά της.

Από όσες υλοποιήσεις εφαρμογών έχω δει μέχρι τώρα που χρησιμοποιούν βάσεις δεδομένων, μπορώ να πώ ότι το να φτιάχνεις κλάσεις που καθρεπτίζουν ένα πίνακα και τα δεδομένα του είναι πολύ πιο βολικό και οδηγεί σε "καθαρότερο" κώδικα, όπου μπορείς να καταλάβεις πιο εύκολα από πού και πώς ήρθε τι (πιο εύκολο debugging ). Όσο μεγαλύτερο το project, τόσο πιο σημαντικό είναι αυτό...

OOP και Database

bigN — Mon, 23 Mar 2009 05:49:36 GMT

Γειά σας,
Είμαι νέος "προγραμματιστης" .... όχι τόσο κατ'επάγγελμα όσο από hobby.
Έχω μια απορρία σχετικά με το ΟΟP προγραμματισμό. Κατανοώ τη χρήση και τη θερωρία του ΟΟP αλλά στην πράξη χολαίνω λίγο.
Έχω φτάξει κατά καιρούς μικρές εφαρμογούλες κυρίως για CF.NET και μου αρέσει πάρα πολύ η C#.
Μέχρι τώρα η ροή κατασκευής των προγραμμάτων μου ακολουθούσε την εξής πορεία --- λίγο design- και περισσότερο coding... Αφού ολοκλήρωνα την εφαρμογή ξεκινούσα την βελτιστοποίησή της όχι τόσο από άποψη λειτουργικότητας αλλά περισσότερα μειώνοντας τις γραμμές του κώδικα και χρησιμοποιώντας class inheritance και overriding methods.
Έτσι λοιπόν φτάνω επιτέλους στο ερώτημα.
ξεκίνησα να φτιάχνω μια εφαρμογούλα την οποία εξαρχής την έχω χωρίσει σε κλάσεις VS2008 Class Diagram, στην πορεία όμως έχω διαπιστώσει ότι θέλω να ενσωματώσω και μια βάση δεδομένων η οποία να κρατούσε τις αρχικές συνθήκες.
Παρατήρησα ότι μερικές από τις κλάσεις μου είναι σχεδόν ίδιες με τους πίνακες της βάσης .... και μου δημιουργήθηκε η εντύπωση ότι η σύνηθης πρακτική είναι οι κλάσεις να είναι "καθρέπτες" των πινάκων της βάσης δεδομένων.
Επομένως το ερώτημά μου είναι ....

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