Progettare librerie di classi.

lunedì 12 novembre 2007 - 19.48

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

sisco22 Profilo | Newbie

43 messaggi | Data Invio: lun 12 nov 2007 - 19:48

Ciao a tutti, data la mia ignoranza riguardo l’argomento avrei bisogno di una dritta su un dubbio riguardante la progettazione di librerie di classi da utilizzare poi nelle mie applicazioni scritte in Visual Basic 2005.

Per esempio... invento... Se dovessi scrivere una serie di librerie di classi, una che si occupi della gestione dei dai dati, un’altra che si occupi della gestione interfaccia utente e via dicendo ... ...

Il dubbio che ho è il seguente:
E' meglio cercare di avere poi un'unica DLL alla quale fare riferimento oppure è meglio avere più DLL magari suddivise per tipologie ?
Grazie per l’attenzione.

Francesco Benini

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 12 nov 2007 - 20:26

>Ciao a tutti,
Ciao!

>data la mia ignoranza riguardo l’argomento avrei
>bisogno di una dritta su un dubbio riguardante la progettazione
>di librerie di classi da utilizzare poi nelle mie applicazioni
>scritte in Visual Basic 2005.
>Per esempio... invento... Se dovessi scrivere una serie di librerie
>di classi, una che si occupi della gestione dei dai dati, un’altra
>che si occupi della gestione interfaccia utente e via dicendo
>...
>Il dubbio che ho è il seguente:
>E' meglio cercare di avere poi un'unica DLL alla quale fare riferimento
>oppure è meglio avere più DLL magari suddivise per tipologie?
Innanzitutto, a mio avviso, seguendo la logica ad Oggetti, direi che ogni classe/oggetto deve implementare la parte che gli compete. Di conseguenza, di sicuro farei le mie classi tutte separate. A prescindere da questo, conta molto lo scope ed in generale la struttura che tu hai intenzione di dare.
Ad esempio, parliamo di operazioni su database? Mi faccio un namespace Miocliente.Mioprogetto.DataManager ad esempio e lì le classi di interfacciamento a database.
Oppure, parliamo di login e utenti? Idem, mi faccio un namespace Miocliente.Mioprogetto.LoginHelper ad esempio, con tutte le classi che mi servono per la gestione dell'utente.
Però, queste due classi, nella mia visione del problema, saranno due DLL separate. Quindi avrò una Miocliente.Mioprogetto.DataManager.dll ed una Miocliente.Mioprogetto.LoginHelper.dll. Un pochino come fa il framework (System.Data.dll, System.IO.dll, ecc..).
Tenderei quindi a dividere la natura delle macroinformazioni trattate (Utenti, Dati, ecc) facendo dll separate dove l'argomento cambia in maniera definita.
Comunque, lascerei spazio anche ad una dll che possa contenere magari metodi che si usano sempre ma che non hanno un legame stretto con un oggetto o un'entità in particolare (conversioni di default, serializzazione, multithread, ecc..). Una sorta di accentratore di metodi (a volte anche shared/static).
Per darti un'idea, ho fatto una classe che gestisce gli oggetti dei database tramite SMO. Miaditta.Utili.SMOManager è una dll autonoma e riutilizzabile ove dovesse servire.
In linea di massima ragionerei così.

>Grazie per l’attenzione.
Di nulla!

Alx81 =)

http://blogs.dotnethell.it/suxstellino

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 !