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 (γι'αυτό υπάρχουν άλλωστε). Σας αφήνω να σκεφτείτε τις εναλλακτικές λύσεις...
Panagiotis Georgiadis
HBM Netherlands B.V.
www.twitter.com/HimWithCurls