[SIForge.org] Principi del Design Orientato agli Oggetti

yag (22 nov 2004, 15:28:02)

Ho una domanda un pò più diretta : ---------------------------------------------------------- con un semplice ragionamento mi pare di capire che la Microsoft sviluppando ado e correlati abbia già studiato e sotto certi aspetti risolto questo genere di problemi (quelli sollevati da Pescio nell'articolo in questione) ora mi domando (in un progetto non reale) ipotizzando che io voglio solo usare ado ho quindi fornito dal framework una architettura che mi permette di fare cose del genere //presi dall'articolo di Pescio Record& r = .... r[ "campo1" ] = 1234 ; r[ "campo2" ] = "abc" ; ora la query "select * from fornitori" dove va messa ? Domanda un pò grezza come dire ma porta subito al sodo quello che serviva a me .... :)

yag (22 nov 2004, 15:20:54)

Hehe ci sono già arrivato a quell'articolo :) ..altre risorse relative al mapping ?

Stefano Fago (22 nov 2004, 08:58:38)

...un punto di vista interessante alle problematiche proposte sono le architetture Record-Oriented...L'idea è quella di applicativi il cui CORE si esprime nella netta separazione tra vista e struttura database-oriented(cursori, record e tabelle) su cui prende il via la logica di business...Per averne una sana trattazione provate qui: http://www.eptacom.net/pubblicazioni/pub_it/ ...E' il sito di Carlo Pescio uno dei massini Guru italiani che ha fatto una trattazione omogenea a riguardo!!!!.... Attenzione però...Questa idea trova facilmente limiti se si va incontro alle problematiche di scalabilità o flessibilità del business, in termini di modellazione! Viene inoltre inserito un livello di complessità che potrebbe essere ridondante in certe situazioni rispetto al semplice mapping!!!! Buon LAvoro!!!! STEFANO FAGO

yag (20 nov 2004, 15:42:59)

per caso ho letto il commento sopra e mi sono reso accorto che trattava le stesse problematiche mie ... ironia della sorte :-) siamo in tanti ad avere probleme hehehe

yag (20 nov 2004, 15:38:58)

inserisco qua la mia domanda anche se non è legata... a questo argomento :) ve lo faccio io un forum se volete :-) ----------------------------------- ho questo problema ho un database con una tab fornitori poi un dataset (preso dal framework) ed una grid (controllo di windows) ed una classe fornitori . riassumento: tab fornitori dataset (preso dal framework) grid (controllo di windows) class fornitori ora mi domando come posso legare tutte queste assieme ? ipotizzando (caso più che classico :-) ) una select del genere "select * from fornitori" come la gestisco a livello di OO e linguaggio di programmazione (nel mio caso c++) tempo fa ho letto un articolo su CP che parlavo dell'object relation mapping c'era pure nel codice ma nn so perchè non mi ha convinto troppo complesso (nel senso disordinato) , troppo limitato (a mio avviso non ricompriva tutti i casi) ed per altri motivi cap. cmq che in un articolo non si può scrivere un framework . quindi chiedevo altre soluzioni più o meno eleganti complicate ecc.

anonimo (05 dic 2003, 17:32:40)

...Allora...Due punti: 1) Dal punto di vista teorico sei nella classica situazione di mapping tra oggetti e db relazionale e a tal proposito c'è una vasta bibliografia...Pensa al fatto che la specifica Enterprise Java Bean(J2ee) nasce per risolvere questa problematica... 2) oltre agli ejb, ci sono più prodotti di mapping che fanno il lavoro per te...Tra questi quello che nel mondo opensource sembra prendere piede è HIBERNATE...La sua diffusione è dovuta alla flessibilità del sistema di mapping object/db, al sistema di autogenerazione file-descriptor/classi e alla capacità di essere cross-db, dato che supporta molteplici dialetti... Se il tuo obiettivo non sono solo gli aspetti pratici(lavoro), per quelli teorici trovi molto in rete...Se vai sulla technet di Oracle hai tanti esempi, che coinvolgono anche lo step XML...Se navighi poi sui progetti open source troverai diversi prodottini ognuno con la loro teoria; tema: O\R MAPPING!... ...facci sapere...

Gildo (27 nov 2003, 17:00:33)

OCP, DIP, ISP, LSP ... le sigle possono essere ostiche, però i concetti che sintetizzano mi piacciono: ho scoperto di averli metabolizzati ancor prima di averne chiara una formalizzazione o una classificazione: è naturale rispettare queste semplici regole, ma non sempre è facile. Il problema che sto affrontando in questi giorni sembra avere le caratteristiche giuste per qualche approfondimento. Sono alle prese con una gerarchia di classi Prodotto - ProdottoBase, ProdottoAlimentare, ProdottoCosmetico - con evidenti relazioni di parentela. I prodotti sono registrati su un unica tabella di Database che prescinde dalle specializzazioni. Ogni singolo prodotto è riconoscibile da una chiave 'ProductID' e contiene un'informazione che permette di riconoscerne il sottotipo. Il Client ha la responsabilità di istanziare un oggetto 'prodotto' acquisendo informazioni dal Database. Dispone però solo della chiave 'ProductID' e non conosce il sottotipo specifico. Come faccio dunque a istanziare un oggetto con il sottotipo corretto avendo a disposizione unicamente una chiave per il Database? Soluzione 1 Una soluzione potrebbe essere quella di progettare un metodo statico su ProdottoBase. Questo metodo estrae l'informazione sul sottotipo attraverso la chiave, istanzia l'oggetto correttamente e lo ritorna al chiamante. Funziona, ma implica che la classe base conosca le classi da essa derivate con buona pace di OCP. Soluzione 1 scartata. Soluzione 2 Ho pensato allora di riciclare perte della soluzione1 delegando il compito di creazione dell'istanza a un metodo factory parametrizzato ospitato da una classe 'ProductCreator'. Anche qui OCP trema perchè l'aggiunta di una nuova specializzazione mi costringe a ritoccare anche 'ProductCreator', ma almeno posso ipotizzare una classe base che non sa nulla dei figli e questo mi è sembrato comunque un risultato importante. Alla fine tuttavia la nuova classe crea problemi agli analisti perchè non appartiene al dominio del problema. Soluzione 2 scartata. A corto di idee non mi rimane che chiedere: c'è una soluzione 3 ? Grazie