Έχω μια μικρή απορία. Χρησιμοποιείς object pooling αλλά το connection string το περνάει ο client. Με τον τρόπο αυτό χάνεις το πλεονέκτημα του pooling για τις συνδέσεις και χρησιμοποιείς το pooling σαν κόφτη για τα connections. Αυτό θέλεις όντως να πετύχεις? Πρόσεξε κιόλας ότι αν βασίζεσαι στο connection pooling αυτό δουλεύει μόνο αν τα connection strings που περνάς είναι ίδια. Θα μπορούσες να χρησιμοποιήσεις το ConstructionEnabledAttribute  για να ορίσεις μέσω του Component Manager  το connection string που θα χρησιμοποιήσει το αντικείμενό σου.

---

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

Και βέβαια, αφού μπορείς να κάνεις post στο Design & Architecture!

Ερώτηση: Γιατί Sparx? Πέρα από την τιμή δηλαδή?

---

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

pkanavos wrote:

Έχω μια μικρή απορία. Χρησιμοποιείς object pooling αλλά το connection string το περνάει ο client. Με τον τρόπο αυτό χάνεις το πλεονέκτημα του pooling για τις συνδέσεις και χρησιμοποιείς το pooling σαν κόφτη για τα connections. Αυτό θέλεις όντως να πετύχεις? Πρόσεξε κιόλας ότι αν βασίζεσαι στο connection pooling αυτό δουλεύει μόνο αν τα connection strings που περνάς είναι ίδια.

Tι εννοείς σαν "κόφτη". Τα connection strings είναι τα ίδια .
Παρα ταύτα μπορείς να μου δώσεις ένα παράδειγμα :

pkanavos wrote:

Θα μπορούσες να χρησιμοποιήσεις το ConstructionEnabledAttribute  για να ορίσεις μέσω του Component Manager  το connection string που θα χρησιμοποιήσει το αντικείμενό σου.

 

---

Πάνος Αβραμίδης

pkanavos wrote:

Και βέβαια, αφού μπορείς να κάνεις post στο Design & Architecture!

Ναί αλλά "χύμα" ... Εδώ έχει υποκατηγορία το Project Management με "τρεις κι κούκος" fans ...

---

Πάνος Αβραμίδης

pkanavos wrote:

Ερώτηση: Γιατί Sparx? Πέρα από την τιμή δηλαδή?

Πέρα από την τιμή, το είδα κα μου άρεσε...

Το αγόρασα επί των ημερών του VS.NET 2002... Αργότερα αγόρασα και την έκδοιση 4 που χρησιμοποιώ ακόμα μια και δεν έχω κοιτάξει έκτοτε τι upgrades έχει βγάλει η Sparx... 

Δεν το χρησιμοποιώ πολύ συχνά γιατί τα τελευταία χρόνια δουλεύω μόνος μου (χωρίς dev teram)....

Όνταν όμως έχω να κάνω ένα μεγάλο project το χρησιμοποιώ για να το αναλύσω σε συνεργασία με τον πελάτη και να "ξέρω" όσο πιο "καλά" γίνεται (με βάση και τα δεδομένα της Ελληνικής αγοράς) τι είναι αυτό που πάω να φτιάξω... Επίσης το χρησιμοποιώ για  να υπάρχει ένα βασικό structural documentation (online κιόλας) για την απίθανη περίπτωση που θα βρεθεί και κανένας άλλος developer να δουλέψει στο ίδιο project μαζί μ' εμένα. (Το χρησιμοποιώ δηλαδή περισσότερο για λόγους αρχής και λιγότερο για πρακτικούς λόγους.. Το Visio είναι ωραίο αλλά όχι για UML. Στο VS.NET 2003 Ent.Arch. ούτε που το κοίταξα για UML modelling με Visio. Μπορεί να είναι και καλύτερο αλλά δεδομένων των συνθηκών ήταν σχεδόν "χάσιμο χρόνου" να ασχοληθώ... Είχα κατά νου να το τσεκάρω σε κάποια στιγμή αλλά μάλλον θα δω μια και καλή το VS.Net 2005.

Γενικά όμως δεν μου αρέσει ΚΑΘΟΛΟΥ το code genration... Οπότε και το Sparx EA δεν το χρησιμοποιώ για code genration... Μόνο για modelling. "Ζωγραφίζω", σκέφτομαι, ανταλλάσω απόψεις με τον πελάτη και αφού καταλήξω σε κάτι λογικό άφήνω στην άκρη το mouse και πιάνω το keyboard....

Έχω χρησιμοποιήσει αρκετές φορές και τον PowerDesigner (τον οποίο προτιμώ για database design) αλλά το sparx είναι πιο light και πιο κοντά σε αυτό ου χρειάζομαι.. (Άσε το κόστος του PowerDesigner...)

rousso

 

 

---

rousso

rousso wrote:

Σε συνέχεια των παραπάνω ο aris ορθώς το έκανε πιο συγκεκριμένο ως ακολούθως:

Πριν πάω στην πρόταση σου Γιάννη (ενοποίηση του MidBase με το Factory)
Επανέρχομαι στο αρχικό θέμα :

Γιατί να χρησιμοποιήσω Factory Οbject για να κάνω instanciate τα objects μου ;
Χοντρικά και σας παρακαλώ διορθώστε με το όλο ζήτημα έγκειται σε πιο σημείο θα γίνει το abstraction.

---

Πάνος Αβραμίδης

Στα γρήγορα: Ένα Factory Object πιθανώς διαβάζει απο κάπου αλλού τους "κανόνες" με τους οποίους σου επιστρέφει instances του interface (ή abstract class τελος πάντων), έτσι ώστε να έχεις μια μεγαλύτερη ευελιξία και να μη χρειάζεται να κάνεις compile και redeploy κάθε φορά που χρειάζεται ν'αλλαξεις / προσθέσεις ένα data source provider.

π.χ. η GetMid() method θα μπορούσε αν γίνει GetMid(string dSourceName) να κάνει ένα lookup για τον κατάλληλο provider για το data source το οποίο δίνεις ως παράμετρο. Εσύ στην πραγματικότητα δεν ξέρεις τι υλοποίηση παίρνεις πίσω, και δε σε νοιάζει κιόλας, εσύ πλέον μιλάς σε ένα MidBase. Αν ΔΕΝ υπήρχε το Factory, και ήθελες να αλλάξεις provider για κάποιο λόγο, θα έπρεπε να διορθώσεις κώδικα και να κάνεις compile - deploy ... με το Factory πιθανώς να χρειάζεται μονο να αλλάξεις ένα entry σ'ενα xml file (λέμε τώρα ... )

---

Angel
O:]

Αυτό ακριβώς δεν καταλαβαίνω, γιατί το ίδιο πράγμα,
μπορώ να το κάνω και χωρίς Factory Object :

Dim hdlSample As ObjectHandle
Dim MyOb As CustomDataManagement.IMid

hdlSample = Activator.CreateInstanceFrom("CustomMid.dll", _
                                                                              System.Configuration. _
                                               ConfigurationSettings. _
                                              AppSettings("MidTierImplementation"))

MyOb = CType(hdlSample.Unwrap, CustomDataManagement.IMid)

With MyOb
   .DoSomething
   .Dispose
End with

---

Πάνος Αβραμίδης

Πάνο το ίδιο πράγμα λέτε...

Απλά είναι πιο κομψό και πιο σωστό να το κάνεις με factory... Ξαναδιάβασε προσεκτικόα αυτό που λέει ο anjelino για re-compilation και re-deployment...

rousso

---

rousso

Γιάννη,
Το θέμα κομψότητας δεκτό ... Το θέμα αλλαγής και scalability όμως ;
Εάν προσθέσω ένα implementation class ή αλλάξω ένα υπάρχον γιατί πρέπει να ξανακάνω compile;

Αφού δουλεύω με interface ή abstact class και αυτό το ιδιότυπο late-bound μηχανισμό του framework.
Δεν αρκεί να πετάξω μέσα στο app directory το όποιο νέο ή αλλαγμένο Dll;

---

Πάνος Αβραμίδης

Όπως τo γράφεις εκεί δεν χρειάζεσαι re-compile (Activator.CreateInstanceFrom("CustomMid.dll", System.Configuration.ConfigurationSettings.AppSettings("MidTierImplementation")))...

Αλλά έτσι θα το γράψεις;;;

Δεν θες να φτιάξεις κάτι πιο generic να το έχεις σε μια βιβλιοθήκη και να μην ξανα-ασχοληθείς με το θέμα;


Επίσης μην ξεχνάς τα implications στο copy/paste deployment που έχουν να κάνουν με code access security, strongly named assemblies κλπ...

Είναι "θέμα αρχής" το να φτιάξεις ένα factory... Κατά τα άλλα κι ο τρόπος που το γράφεις δουλεύει μια χαρά χωρίς recompile. Αλλάζεις το .config και παίζει με άλλο DAL...

Για το scalability δεν κατάλαβα τι εννοείς... (;)

rousso

---

rousso

Όπως τo γράφεις εκεί δεν χρειάζεσαι re-compile (Activator.CreateInstanceFrom("CustomMid.dll", System.Configuration.ConfigurationSettings.AppSettings("MidTierImplementation")))... Αλλά έτσι θα το γράψεις;;; Δεν θες να φτιάξεις κάτι πιο generic να το έχεις σε μια βιβλιοθήκη και να μην ξανα-ασχοληθείς με το θέμα

Ναι ναι ... δεν διαφωνώ απλά ρωτάω από περιέργεια ...

Για το scalability δεν κατάλαβα τι εννοείς... (;)

Προσθήκη και άλλου databasource management implementation...

---

Πάνος Αβραμίδης

Κάτι ακόμη η περίπτωση το abstraction να γίνει ένα επίπεδο πιο κάτω πως ακούγεται δηλαδη :

Ένα Class με generic funcionalities (πχ inParams : spNameToExecute επιστρέφει dataset) όπου τα 
Connection/ Data Reader/Adapter objects θα δημιουργούνται late bound σe runtime;
 

---

Πάνος Αβραμίδης

Καθόλου! Πολύ καλό!

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

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

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

Καλημέρα μας !

Υ.Γ ... α! Επίσης, η διαφορά μεταξύ της χρήσης ενός 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 )

---

Angel
O:]