Classi Tabelle : to be or not to be ?

[djciko]

Premesso il fatto che andro' leggermente OT, volevo chiedere una opinione alla comunità...

Stasera mi sono soffermato con due responsabili (programmatori VB6) dell'azienda nella quale lavoro, parlando di automazione sulle operazioni con le varie tabelle di un progetto su cui stiamo lavorando.

La loro tesi era che per ogni tabella ci dovrebbe essere una classe (.vb) che gestisce le operazioni fondamentali su di essa.
Vorrebbero, praticamente, creare dei metodi che vadano a recuperare i nomi dei campi delle tabelle ed altri che settino proprieta' pubbliche poi consumabili all'interno delle applicazioni.

Ora, ho ragione a pensare che questa e' una problematica che non andrebbe affrontata per niente, implementando una classe quando vale la pena implementarla e non quando si vuole soltanto scimmiottare la metodologia ad oggetti ?

Al limite, io mi sono prodigato per sviluppare una classe con due proprieta' settabili, la stringa di connessione e la query che si vuole eseguire, e vari metodi per ottenere un DataSet o un SqlDataReader, o che ne so, per contare i record (visto che i metodi sull'oggetto command sono leggermente diversi...) :

uno dei metodi, ad esempio:

Public Function Estrai As DataSet
 Connetti()
 internal_DATASET    = New DataSet()
 internal_SQLADAPTER = New SqlDataAdapter(StringaSQL, internal_SQLCONN )
 internal_SQLADAPTER.Fill ( internal_DATASET, "dtable" )
 internal_SQLCONN.Close()
 Return internal_DATASET
End Function

Datemi un'opinione sulla faccenda.

[riccardone]

Originariamente inviato da djciko
La loro tesi era che per ogni tabella ci dovrebbe essere una classe (.vb) che gestisce le operazioni fondamentali su di essa.
Vorrebbero, praticamente, creare dei metodi che vadano a recuperare i nomi dei campi delle tabelle ed altri che settino proprieta' pubbliche poi consumabili all'interno delle applicazioni.

Un data access layer degno del nome dovrebbe fornire al livello di business tutti i metodi necessari per fare il cosiddetto crud (CRUD = Create, Read, Update , Data) sulle tabelle importanti.

Ora, ho ragione a pensare che questa e' una problematica che non andrebbe affrontata per niente, implementando una classe quando vale la pena implementarla e non quando si vuole soltanto scimmiottare la metodologia ad oggetti ?

non ho capito che vuoi dire. Se si ritiene di voler sviluppare una applicazione su due o tre livelli per permetterne una migliore gestione non significa scimmiottare niente ma semmai cercare di evitare problemi futuri. Nel caso specifico da quel poco che hai detto, i tuoi colleghi sembrano voler fare un sistema che permetta di dover riscrivere le classi di accesso ai dati nel momento in cui cambia il database sottostante. Una specie di commandbuilder fatto a manina insomma con l'aggiunta di classi piene delle proprieta' per interagire con esse create al volo (probabilmente con reflection).

Al limite, io mi sono prodigato per sviluppare una classe con due proprieta' settabili, la stringa di connessione e la query che si vuole eseguire, e vari metodi per ottenere un DataSet o un SqlDataReader, o che ne so, per contare i record (visto che i metodi sull'oggetto command sono leggermente diversi...) :

posso consigliarti, se devi usare funzioni cosi generiche, di dare una occhiata al Microsoft Data Application Block. E' una libreria di classi utili per l'accesso ai dati
http://tinyurl.com/584fd

[djciko]

non ho capito che vuoi dire. Se si ritiene di voler sviluppare una applicazione su due o tre livelli per permetterne una migliore gestione non significa scimmiottare niente ma semmai cercare di evitare problemi futuri. Nel caso specifico da quel poco che hai detto, i tuoi colleghi sembrano voler fare un sistema che permetta di dover riscrivere le classi di accesso ai dati nel momento in cui cambia il database sottostante. Una specie di commandbuilder fatto a manina insomma con l'aggiunta di classi piene delle proprieta' per interagire con esse create al volo (probabilmente con reflection).

Ti assicuro che non vogliono fare nulla di tutto questo. Ma solo adottare le filosofie di VB6 (ereditarietà?) con Asp.net. Parlavano di settare una proprietà della classe che consisteva in una collection fatta di nomi dei campi...e la classe stessa poi, con un metodo Init, avrebbe dovuto scrivere da sola le istruzioni di Insert, Update, Cancel accessibili poi con dei metodi tipo Salva, Aggiorna etc.... Era la filosofia, la cosa su cui non mi trovavano d'accordo. Problemi di questo genere non si risolvono volendo adottare le vecchie metodologie (vb6, appunto) in un linguaggio come asp.net...Sei d'accordo ?

Do'una occhiata al link, grazie mille.

[biste]

Non esiste una regola che permette di affermare che c'è sempre una corrispondenza 1:1 tra tabelle/classi; in alcuni casi questo può essere vero, in molti altri no.
Chi sostiene la teoria del mapping 1:1 in .NET utilizza solitamente classi DataSet tipizzate per rappresentare le entità perchè è molto facile generare automaticamente le classi in questo modo (con definizione XSD e tool tipo xsd.exe). Questa soluzione però per esperienza può legare molto l'applicazione e limitarne la scalabilità.
Come detto prima dipende dall'applicazione, ma credo potrebbe esserti utile analizzare anche il lavoro che fanno alcuni tool detti Object Relational Mapping (ORM), nati proprio per questi scopi. Una lista di quelli per la piattaforma .NET puoi trovarla su: http://www.theserverside.net/news/th...hread_id=29914

Se hai occasione (e se ci sono ancora posti) ti consiglierei di seguire il workshop (gratuito) di UGIdotNET che ci sarà giovedì dove in una sessione si parlerà proprio di Typed DS vs. Custom Entities; in alternativa potrai consolarti tra qualche giorno scaricando le slide e gli esempi utilizzati.

HTH

[riccardone]

Originariamente inviato da djciko
...la classe stessa poi, con un metodo Init, avrebbe dovuto scrivere da sola le istruzioni di Insert, Update, Cancel accessibili poi con dei metodi tipo Salva, Aggiorna etc....

come detto sembra essere un commandbuilder fatto amanina.

[djciko]

Se hai occasione (e se ci sono ancora posti) ti consiglierei di seguire il workshop (gratuito) di UGIdotNET che ci sarà giovedì dove in una sessione si parlerà proprio di Typed DS vs. Custom Entities; in alternativa potrai consolarti tra qualche giorno scaricando le slide e gli esempi utilizzati.
HTH

Grazie per i consigli, purtroppo sono molto lontano.
Non manchero' di scaricare il tutto, comunque.

Riccardo, perdona l'ignoranza..cos'e' precisamente un CommandBuilder ?

[riccardone]

Originariamente inviato da djciko
..cos'e' precisamente un CommandBuilder ?

Una classe che partendo da una istruzione di select su una tabella genera le relative istruzioni di update insert e delete in automatico.