Conversione da programmazione procedurale --> ad oggetti ... qualche c...

martedì 26 aprile 2011 - 18.19

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags VB.NET

franksnet Profilo | Newbie

41 messaggi | Data Invio: mar 26 apr 2011 - 18:19

Buongiorno,

ho sviluppato in passato software in VB .NET con impostazione procedurale, e attualmente, viste le accresciute dimensioni del software, sto cercando di riscrivere il tutto secondo la programmazione ad oggetti, con un paradigma di tipo MVVM (sto usando WPF per l'interfaccia)

A livello teorico mi è ben chiaro il vantaggio di una separazione totale dei vari layer ... ma nella pratica, ci son dei passaggi che mi pare creino una ridondanza e una rigidità controproducente. Nello specifico, faccio un esempio: se io devo accedere a dei dati archiviati in un database, e la struttura di queste tabelle può spesso cambiare a seconda dei dati che nel tempo è necessario gestire, che vantaggio mi porta un sistema a oggetti se per ogni tabella devo crearmi una classe nel programma e mantenerla aggiornata? Se ho 100 tabelle, devo creare 100 classi, e magari in varie tabelle tutti i mesi potrò avere qualche modifica ... diventa un incubo ...

E' vero che ci son automatismi che permettono di fare questo senza doverci pensare manualmente, ma non vedo il vantaggio rispetto ad altre soluzioni. Ad esempio, mi ero creato un sistema (di tipo procedurale) per cui all'apertura di un form passandogli alcuni parametri questo era in grado in automatico di consentire operazioni CRUD sulla tabella mediante uso di DataGridView (oppure di un data form composto da TextBox, Button etc), facendo una validazione dei dati basata sul tipo di colonna etc
Questo, in pratica, semplicemente dando come parametro il nome della tabella. E se aggiungo una colonna, se ne accorge da solo perchè i dati li estrapola a runtime

Non riesco a capire come implementare una soluzione di questo genere mediante un modello di tipo MVVM, se tutte le spiegazioni che ho trovato in materia prevedono il ricorso a un mapping basato su classi da compilare nel sorgente ... qualcuno mi da una mano?! :-)

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: ven 13 mag 2011 - 13:09

>Buongiorno,
Ciao

>A livello teorico mi è ben chiaro il vantaggio di una separazione
>totale dei vari layer ... ma nella pratica, ci son dei passaggi
>che mi pare creino una ridondanza e una rigidità controproducente.
>Nello specifico, faccio un esempio: se io devo accedere a dei
>dati archiviati in un database, e la struttura di queste tabelle
>può spesso cambiare a seconda dei dati che nel tempo è necessario
>gestire, che vantaggio mi porta un sistema a oggetti se per ogni
>tabella devo crearmi una classe nel programma e mantenerla aggiornata?
>Se ho 100 tabelle, devo creare 100 classi, e magari in varie
>tabelle tutti i mesi potrò avere qualche modifica ... diventa
>un incubo ...
Per quale motivo dovresti mappare le tabelle una ad una? Il modello ad oggetti dell'applicazione, è il modello ad oggetti dell'applicazione.
Il database, tramite l'ausilio di stored procedure ad esempio, può tornarti quella che per te è l'entità, non necessariamente 1:1 per ogni campo..
Noi usiamo MVVM da ormai un paio di anni, e devo dire che i vantaggi, anche pratici, sono tanti.
Tutti i propertychanged, tutto il binding verso l'interfaccia.
Ci si rende ben astratti e la manutenibilità è molto migliore.. Ma questo credo sia a prescindere dal problema che ti poni, che vedo più verso "db vs modello ad oggetto".
Dipende sempre come tu vuoi rendere forte il legame tra lo strato di dati ed il modello ad oggetti.
C'è anche chi usa linq, chi fa dell'SQL dinamico, ecc..

>Non riesco a capire come implementare una soluzione di questo
>genere mediante un modello di tipo MVVM, se tutte le spiegazioni
>che ho trovato in materia prevedono il ricorso a un mapping basato
>su classi da compilare nel sorgente ... qualcuno mi da una mano?! :-)
Noi abbiamo n DAL, n BIZ, e per ogni strato, interfacce. Idem verso il WCF, contratti ed interfacce. Una volta arrivati al WPF abbiamo un ViewModel che consuma un modello comune (visibile trasversalmente da ogni livello) e che rende fruibili i binding verso il presentation.

--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi

Bazzi Profilo | Junior Member

67 messaggi | Data Invio: ven 3 giu 2011 - 17:01

Buongiorno,

scusate se mi intrufolo nella discussione, ma mi interessa parecchio. Io sono da anni programmatore Cobol e sono entrato nel mondo Object Oriented da circa 3 anni, attraverso dei corsi che mi sono autofinanziato e passando le mie nottate a studiare e sviluppare procedure gestionali in vb.net e c#.
Quello che sto cercando di apprendere e prendere come abitudine è di pensare ad oggetti.
Così ho iniziato a sviluppare un sw ponendomi l'imperativo di dividere la gestione delle form, le funzioni di logica e le operazioni sul DB.
Anch'io, però, sono arrivato a gestire una classe per ogni tabella del DB. E mi sono detto che forse, non è la modalità migliore.
A questo punto, mi chiedo e vi chiedo : esistono testi (magari in italiano) o siti con esempi di come strutturare software in modo ottimale ?
Insomma, vorrei capire, come viene scritto un sw in .Net in maniera ottimizzata. Quindi esperti .Net...datemi qualche dritta !

Ciao e grazie a tutti.
The Bazz

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 20 giu 2011 - 07:02

>Buongiorno,
Ciao

>Quello che sto cercando di apprendere e prendere come abitudine è di pensare ad oggetti.
>Così ho iniziato a sviluppare un sw ponendomi l'imperativo di dividere la gestione delle form, le funzioni di logica e le operazioni sul DB.
>Anch'io, però, sono arrivato a gestire una classe per ogni tabella
>del DB. E mi sono detto che forse, non è la modalità migliore.
Mah.. è una scelta, non credo ci sia una via migliore in realtà.
Se ti basta il modello relazionale del database e se l'applicazione è database driven, ti viene anche comodo fare così.

>A questo punto, mi chiedo e vi chiedo : esistono testi (magari
>in italiano) o siti con esempi di come strutturare software in
>modo ottimale ?
>Insomma, vorrei capire, come viene scritto un sw in .Net in maniera
>ottimizzata. Quindi esperti .Net...datemi qualche dritta !

esistono pattern. E tanti. Dai una letta a questo post:
http://www.dofactory.com/Patterns/Patterns.aspx

In realtà questo è proprio un annoso problema. Quei pattern ti spiegano come architettare il software, ma per il colloquio con il database, la cosa non è sempre semplice.
Personalmente ritengo che più che una classe per tabella sia meglio l'approccio entità/classe, dove l'entità, non necessariamente è una sola tabella.
E' la parte elementare di un tuo modello che è trasversale a più livelli, genericamente indicati come BL (Business Layer) e DAL (Data Access Layer).
Il primo decide le logiche da effettuare utilizzando il modello creato, il secondo effettua la chiamata a database, sempre utilizzando lo stesso modello, conosciuto da entrambi i livelli di astrazione.
--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi

Bazzi Profilo | Junior Member

67 messaggi | Data Invio: mar 21 giu 2011 - 11:38

Grazie per la risposta !

The Bazz

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !