Evitare codice Hard Coded

giovedì 27 settembre 2007 - 09.47

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Teech Profilo | Expert

573 messaggi | Data Invio: gio 27 set 2007 - 09:47

Questo mio dubbio è più a livello logico che non tecnico puro...

Mi pare sia impossibile evitare di indicare in modo Hard Coded dei dati quando si utilizzano DB e classi per la gestione delle tabelle... Nello specifico ho un DB con 3 tabelle: Anagrafiche, TipiAnagrafiche e AnagraficheTipizzate. Nella tabella anagrafiche ho i dati "generali" (Ragione Sociale, indirizzo CAP, ecc...), nella tabella TipiAnagrafiche ho una gestione dei tipi con Codice e Descrizione (C= Cliente, F=Fornitore, ecc...) e nella tabella AnagraficheTipizzate ho una relazione fra le tabelle dove, ad esempio, l'anagrafica codice 101 può essere sia cliente che fornitore.
In questo modo riesco a dare massima flessibilità all'utente del programma che può tipizzare le proprie anagrafiche come crede (può creare un codice nella tabella TipiAnagrafiche T=Contatti ad esempio). Per gestire il tutto ho una classe che mi gestisce la tabella Anagrafiche e vorrei crearmi delle classi derivate per ogni tipologia... Essendo le tipologie dettate dall'utente questo non è possibile e quindi il tutto viene demandato ad una selezione del tipo nelle Form dell'applicazione mantenedo la massima astrazione...

Un approccio alternativo potrebbe essere quello di utilizzare tabelle distinti per i tipi, eventualmente usando dei "macrotipi". Esempio:
TipiAnagrafiche: C=Clienti Italia con macrotipo C, K=Clienti Esteri con Macrotipo C, F=Fornitori Italia com Macrotipo F, ecc..
In questo modi riuscirei a gestire delle classi specializzate di Anagrafica ereditando ma per definire il tipo/macrotipo devo utilizzare del codice Hard Coded (eventualmente un ENum per i macrotipi) e preferirei evitarlo...

Un altro approccio è creare tabelle diverse per ogni macrotipo (Tabella Clienti, Tabella Fornitori, ecc..) ma questa soluzione mi pare ancora più rigida rispetto alla precedente...

Nella soluzione stò cercando di astrarre il più possibile utilizzando stored procedure per la gestione dei command sul DB, aumentando i livelli fra le classi base e l'interfaccia utente attraverso classi sempre più specializzate e per questo motivo vorrei evitare codice Hard Coded o legarmi ad una struttura rigida e troppo tipizzata del DB

Finalmente la domanda:
Conoscete delle tecniche per utilizzare il primo metodo esposto e specializzare le classi in modo "dinamico" o meglio creare delle classi che si specializzano in modo dinamico?
Ma soprattutto il mio ragionamento è corretto rispetto agli standard del software engeneering?

Grazie dell'attenzione e dell'eventuale aiuto :-)

Ciao!!!
--------------
Maurizio Brini
--------------
Nessuna impresa è mai stata compiuta da un uomo ragionevole

Brainkiller Profilo | Guru

7.999 messaggi | Data Invio: ven 28 set 2007 - 11:16

>Finalmente la domanda:
>Conoscete delle tecniche per utilizzare il primo metodo esposto
>e specializzare le classi in modo "dinamico" o meglio creare
>delle classi che si specializzano in modo dinamico?

Bella domanda

Forse con LINQ cambierà qualcosa. In genere però qualcosa di fisso dovrebbe esserci in un'applicazione. Una base dati bisognerebbe progettarla e poi implementarla. Se l'utente può dinamicamente crearsi parti di base di dati (tabelle ecc.) salta un po' tutto. Io sconsiglio sempre questo approccio. Anche perchè come sai poi in una tabella ci sono chiavi primarie, relazioni, indici, ecc.ecc. tutte cose da tenere in considerazione.

Se da un lato creare nuove tabelle con SQL Server è più facile è un po' più complesso invece creare classi dinamicamente. Comunque il Framework consente anche questo.

David De Giacomi | Microsoft MVP
http://blogs.dotnethell.it/david/

Teech Profilo | Expert

573 messaggi | Data Invio: dom 30 set 2007 - 15:35

Qundi, diciamo che l'astrazione completa rispetto al DB non esiste.
La struttura delle classi che gestiscono dati su DB viene logicamente tipizzata dalla struttura dei DB sottostanti. La massima struttura astratta deriva dall'astrazione logica delle tabelle e relative relazioni. Posso in qualche modo prescindere dal DBMS ma non dalla struttura in esso contenuta.

Nel mio caso posso utilizzare dei "macrotipi" per le anagrafiche mettendoli hard coded nel codice dell'applicazione e scrivere questi macrotipi nella tabella dei tipi senza relazionarli a nulla nel DB ma sarà la procedura stessa a trascodificare, secondo una sua logica, quanto indicato nel campo del macrotipo per inizializzare la classe tipizzata corretta... Avrò un dato all'interno della mia tabella che non sarà significatovo se preso a se stante dal DB ma solo se processato dall'applicazione.

Avrò una tabella dei tipi così composta (ad esempio):
Codice,Descrizione,Macrotipo
1,Clienti Italia,C
2,ClientiEstero,C
3,Fornitori Italia,F
4,Fornitori Estero,F
5,Contatti,A
In questo caso, il macrotipo da solo non ha nessun significato se non trascodificato dal codice dell'applicazione...

Quando "tipizzo" le anagrafiche mi troverò con una tabella così composta:
CodiceAnagraficaGenerica,CodiceTipo
101,1 <--Cliente e fornitore italiano
101,3 <--Cliente e fornitore italiano
105,3 <--Fornitore italiano

Leggengo l'anagrafica tipizzata nella mia tabella di tipizzazione potrò decidere quale classe specializzata istanziare in base al macrotipo.
Sbaglio?

P.S.: Questo è un esempio tanto per capire...

Ciao e grazie...
--------------
Maurizio Brini
--------------
Nessuna impresa è mai stata compiuta da un uomo ragionevole

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 !