Καλώς ορίσατε στο dotNETZone.gr - Σύνδεση | Εγγραφή | Βοήθεια
σε

 

Αρχική σελίδα Ιστολόγια Συζητήσεις Εκθέσεις Φωτογραφιών Αρχειοθήκες

Interface programming

Îåêßíçóå áðü ôï ìÝëïò axaros. Τελευταία δημοσίευση από το μέλος axaros στις 25-10-2005, 11:19. Υπάρχουν 64 απαντήσεις.
Σελίδα 3 από 5 (65 εγγραφές)   < 1 2 3 4 5 >
Ταξινόμηση Δημοσιεύσεων: Προηγούμενο Επόμενο
  •  31-08-2005, 10:43 4843 σε απάντηση της 4841

    Απ: Interface programming

    Άγγελε καλημέρα !!!

     anjelinio wrote:
    Αν κατάλαβα καλά, εννοείς να φτιάξεις μια κλάσση η οποία χρησιμοποιεί interfaces (IDataReader κτλ κτλ) για να εκτελέσει τα DB calls σου, όπου τα implementations αυτών των interfaces τα παίρνει απ'τον εκάστοστε data source provider σου;

    Σε αυτή την περίπτωση, είναι σαν να έχεις μια abstract base class για τους providers σου, με τη διαφορά οτι "σπάς" αυτό το functionality σε 2 κλάσσεις, αυτή τη generic class (η οποία θα περιεχόταν στην abstract base), και στον actual provider που φτιάχνει τα DataAdapters κτλ κτλ .. οπότε ... μικρή η διαφορά, αλλά και πάλι θα προτιμούσα τη λύση με την abstract base.

    Αυτό περιέγραφα ... Απλά προσπαθώ να σκεφτώ σενάρια για να "χωνέψω" το θέμα abstraction. 

     anjelinio wrote:

    Υ.Γ ... α! Επίσης, η διαφορά μεταξύ της χρήσης ενός Factory με εξωτερικό config file και της χρήσης του App/Web.Config όπως το έχεις στον κώδικα παραπάνω, είναι οτι με το Web.Config περιορίζεις τον εαυτό σου σε ένα setting που αφορά datasource provider. Στο Factory θα μπορούσες να ορίζεις σε ένα εξωτερικό xml πολλά data sources, το καθένα με attribute τον τύπο του εκάστοτε provider και να παίρνεις πίσω instance by data source name, κάπως έτσι:

    MidBase myMainDataSourceProvider = MidFactory.CreateInstance("my_primary_datasource");
    MidBase myOtherDataSourceProvider = MidFactory.CreateInstance("my_logging_datasource);

    Θα μπορούσες να το κάνεις και χωρίς το εξωτερικό xml, και με το εκάστοτε xxx.Config και χωρίς το Factory φυσικά, απλώς "αισθητικά" είναι πιο καθαρό να έχεις το Factory. Θα γινόταν ένας μικρός χαμός στο xxx.Config σου, και ο κώδικας σου θα ήταν αναγκαστικά πιο μπερδεμένος ( λέω εγώ τώρα, έτσι; Δεν σημαίνει απαραίτητα οτι ισχύουν κι όλα αυτά :D )


    Έχεις δίκιο και εσύ και οι υπόλοιποι ... Είναι σίγουρα πολύ καλύτερο design το Factory.


    Πάνος Αβραμίδης
  •  31-08-2005, 10:51 4844 σε απάντηση της 4843

    Απ: Interface programming

    Παλληκάρια, μια ερώτηση - εύλογη απορία (συγνώμη αν ακουστώ γραφικός, αλλά δεν μπορούσα να μην την ρωτήσω).

    Ακούω για factories, abstractions, κλπ κλπ. Αν το DAL δεν υλοποιείται υπό μορφή ασκησης και μεσου για να κατανοήσουμε καλύτερα τις αρχές σχεδίασης και θέλουμε έμφαση στο τελικό αποτέλεσμα, γιατί δεν ρίχνετε μια ματιά στο Data Access Application Block του Enterprise Library;

    Παλι αν ο στόχος είναι άλλος, να με συγχωρέσετε. Απλά δεν είδα κανέναν να το αναφέρει και απόρησα. Δεν έχω διαβάσει προσεκτικά όλο το thread και μπορεί κάτι να μου ξεφέυγει.
    Σωτήρης Φιλιππίδης

    DotSee Web Services

    View Sotiris Filippidis's profile on LinkedIn

    DotNetNuke them!
  •  31-08-2005, 11:14 4845 σε απάντηση της 4844

    Απ: Interface programming

    Σωτήρη μάλλον εγώ θα ακουστώ γραφικός : αγνοούσα καν την ύπαρξη του ...
    Θα κάτσω να διαβάσω στην πρώτη ευκαιρία.
    Σε ευχαριστώ πολύ !!!


    Πάνος Αβραμίδης
  •  31-08-2005, 11:30 4847 σε απάντηση της 4845

    Απ: Interface programming

    Νομίζω οτι πλέον το κυρίως θέμα του thread τούτου είχε ξεφύγει απ'τα πλαίσια ενός DAL, και έτεινε προς Design θέματα... ξεστρατίσαμε, αλλά προσωπικά πιστεύω οτι είναι και λίγο ιδεολογικό το θέμα με τα μύρια application blocks της μαμάς ... σε λίγο καιρό θα γίνουμε copy-paste monkeys όπως πάει αυτή η ιστορία ( υπερβάλλω, αλλα οκ, είναι η πικρή αλήθεια οτι το εκάστοτε Application Block σε "προστατεύει" απ'το να μάθεις την πλατφόρμα πάνω στην οποία εργάζεσαι σε λίγο περισσότερο βάθος )

    Αν στόχος είναι το rapid development όμως, πάσο. Αλλά πιστεύω οτι πρέπει να γράψεις μερικές φορές το functionality μόνος σου πρώτα - αν μη τι άλλο για να μπορείς να δείς το application block και με λίγο κριτικό μάτι.
    Angel
    O:]
  •  31-08-2005, 11:40 4850 σε απάντηση της 4847

    Απ: Interface programming

    Άγγελε συμφωνώ μαζί σου ... Άλλωστε το design μέρος έχει ενδιαφέρον ανεξάρτητα από οποιοδήποτε DAL.
    Απλά δεν ήξερα ότι υπάρχει το Enterprize Library. Να το δω θέλω ...

    Εξάλλου έχει μείνει στη μέση η ανάλυση της λύσης του Γιάννη 
    που ενσωματώνει την Base (abstact class) με το Factory ...


    Πάνος Αβραμίδης
  •  31-08-2005, 11:47 4851 σε απάντηση της 4847

    Απ: Interface programming

    Ναι, ναι, συμφωνώ απόλυτα! Γι΄αυτό και ανέφερα το στόχο. Αν ο στόχος ήταν κάποιο γρήγορο αποτέλεσμα μόνο και μόνο τότε είχε νόημα η πρότασή μου να δούν τα παιδιά το DAAB.

    Το June 2005 download μπορείτε να το βρείτε εδώ


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

    DotSee Web Services

    View Sotiris Filippidis's profile on LinkedIn

    DotNetNuke them!
  •  31-08-2005, 12:18 4853 σε απάντηση της 4851

    Απ: Interface programming

    Και συνεχίζω με τη λύση του Γιάννη :

     rousso wrote:

    Ο τρόπος που το κάνω εγώ συνήθως είναι λίγο διαφορετικός αλλά θέλει
    λίγη ανάλυση για να μπω σε αυτή την διαδικασία τώρα. Σε κάποια στιγμή
    θα το βάλω στο blog μου.


    Η οποία με έμπλεξε λίγο Confused [8-)]...

     


    Πάνος Αβραμίδης
  •  31-08-2005, 13:41 4854 σε απάντηση της 4853

    Απ: Interface programming

    Πάνο, πες μας πιο συγκεκριμένα τι είναι αυτό που σε μπερδέυει να προσπαθήσω να το κάνω πιο ξεκάθαρο.

    rousso

    υ/γ: μπορώ να σου γράψω τον κώδικα (σε draft) αν θες αλλά ο χρόνος μου αυτές τις μέρες είναι πάρα πολύ περιορισμένος...

    rousso
  •  31-08-2005, 14:12 4855 σε απάντηση της 4854

    Απ: Interface programming

    Γιάννη όντως θα μπορούσες να γράψεις ένα draft όποτε βρεις ευκαιρία;
    Το ξέρω ότι είναι δύσκολο να αφιερώσετε χρόνο σε παραδείγματα και
    πραγματικά εκτιμώ ιδιαίτερα όσες προσπάθειες γίνονται.

     


    Πάνος Αβραμίδης
  •  31-08-2005, 19:16 4862 σε απάντηση της 4855

    Απ: Interface programming

    Στα γρήγορα...

    Mid.cs:

    using System;
    using System.Data;
    using System.Reflection;
    
    namespace rousso
    {
    
    	public abstract class Mid
    	{
    		
    		virtual public DataSet GetData()
    		{
    			return null;
    		}
    
    		// factory
    		static public Mid GetMid(Type midType)
    		{
    			if (!midType.IsSubclassOf(MethodBase.GetCurrentMethod().ReflectedType))
    				throw new ApplicationException("I only create instaces of my sub-classes!");
    			
    			return (Mid) Activator.CreateInstance(midType);
    		}
    	}
    }
    

     

    SMid.cs

    using System;
    using System.Data;
    using System.Data.SqlClient;
    
    namespace rousso
    {
    	/// <summary>
    	/// Summary description for SMid.
    	/// </summary>
    	public class SMid : Mid
    	{
    		public SMid()
    		{
    			//
    			// TODO: Add constructor logic here
    			//
    		}
    
    		override public DataSet GetData()
    		{
    			DataSet dataSet = new DataSet();
    
    			//
    			// TODO: Write applicable code to fill the dataSet
    			//
    
    			return dataSet;
    		}
    
    	}
    }
    

    Αντίστοιχα και το AMid.cs και όποιο άλλο θες

     

    Για να φτιάξεις ένα object:

    Mid m = Mid.GetMid(typeof(SMid));
    

     

    Εννοείται ότι μπορείς να βάλεις ό,τι overloads θέλεις και αντί να περνάς το Type να περνάς το Type Name σαν string κλπ Επίσης εννοείται ότι δεν έχω βάλει τις υπόλοιπες παραμέτρους που χρειάζεσαι για λόγους συντομίας..

    got it?

    rousso


    rousso
  •  01-09-2005, 10:19 4883 σε απάντηση της 4862

    Απ: Interface programming

    Γιάννη νομίζω ότι σε πιάνω ....
    Είμαι υπόχρεος για άλλη μια φορά ....

    Στην δική σου μεθοδολογία (ενσωμάτωση του Factory στο generic ob) το συν
    σε σχέση με την πιο κλασσική του ξεχωριστού Factory
    είναι η κομψότητα του exemption handling μόνο ή δεν βλέπω κάτι;


    Πάνος Αβραμίδης
  •  01-09-2005, 10:43 4885 σε απάντηση της 4883

    Απ: Interface programming

    • Χρειάζεται να θυμάσαι λιγότερα class names. 
    • Χρειάζεται να γράψεις λιγότερες classes.
    • Η ονοματολογία των classes είναι πιο "κομψή".
      (Αν και την factory method θα έπρεπε να την είχα ονομάσει CreateMid ή CreateInstanceOf ή CreateNew ή κάτι τέτοιο καθως το GetMid σου δεν σου δίνει την αίσθηση του factory/creation)
    • Αυτόματα η SMid και οι άλλες sub-classes κληρονομούν την GetMid() με όλες τις προεκτάσεις που μπορεί να έχει αυτό στο sub-classing των sub-classes..

    Επίσης πρόσεξε ότι στην factory method γράφω

    if (!midType.IsSubclassOf(MethodBase.GetCurrentMethod().ReflectedType))

    ενώ θα μπορούσα να γράψω

    if (!midType.IsSubclassOf(typeof(Mid)))
    Ως "άσκηση" προσπάθησε να καταλάβεις γιατί το έκανα έτσι ενώ θα δούλευε και το απλούστερο typeof(Mid)...

    you are welcome
    rousso


    rousso
  •  01-09-2005, 11:05 4887 σε απάντηση της 4885

    Απ: Interface programming

    Γιάννη σε ευχαριστώ θερμά !!!!!


    Πάνος Αβραμίδης
  •  01-09-2005, 11:30 4890 σε απάντηση της 4885

    Απ: Interface programming

    Να κάνω μια μικρή παρέμβαση, και να προτείνω να δηλώσεις την GetData(...) ως abstract στην κλάσση Mid, έτσι ώστε να υποχρεώνεις κάθε subclass να παρέχει ένα implementation αυτής της μεθόδου;
    Angel
    O:]
  •  01-09-2005, 13:13 4921 σε απάντηση της 4890

    Απ: Interface programming

    Δεν μπορείς να κάνεις μια static abstract. Το abstraction απαιτεί instances για να δουλέψει.

    Επίσης δεν θέλω να είναι abstract ή virtual instance method.
    Αν κάποιο sub-class θέλει να την κάνει "override" τότε (μια και το overriding απαιτεί επίσης instances) την κάνει hide (με new static public Mid GetMid(...) κλπ) και αν θέλει καλεί και το base implementation (hint: βλ. την άσκηση που έβαλα στον axaros στο προηγούμενο post μου).

    rousso

    rousso
Σελίδα 3 από 5 (65 εγγραφές)   < 1 2 3 4 5 >
Προβολή Τροφοδοσίας RSS με μορφή XML
Με χρήση του Community Server (Commercial Edition), από την Telligent Systems