Spesso mi sono trovato di fronte ad una problematica che sarà capitata ad ognuno di voi: come scrivere un'applicazione che possa supportare piu' database e che sia di facile manutenzione nel tempo?
L'esempio che ho scritto non contiene nulla di innovativo, è solo un mix di tecniche di programmazione già note, che però risolvono agevolmente il problema sopra citato.
L'esempio è costituito da tre progetti: il Business layer, il DataLogic layer, l'Entities e un progettino di test che sfrutta quel modello. A seconda del tipo di database che si specifica nel file .config, viene istanziato quello o quell'altro sqlclient (nel mio caso ho fatto un esempio con SqlClient e OleDB, ma vedrete che è banale estenderlo ad Oracle, MySQL ecc...).
Nota: la mia non è una serie di librerie universali da usare in tutti i progetti, ma un modello di esempio di come dovrebbero essere scritte le librerie di accesso ai dati.
Potete scaricare il progetto da
questo link.
Ogni commento, critica o suggerimento per migliorare il modello è molto ben accetto!
In un messaggio inviato oggi nella ML di sviluppo di Mono, il project leader Miguel De Icaza ha chiesto quanto segue:
Hello,
We have always been thinking that the next release of Mono would be
"1.2" which would flag an incremental update to Mono 1.0, but this is a
relatively large update as it contains a lot of functionality that was
not in Mono 1.0.
I would even go as far as saying that we could feel confident that
this could be called "Mono 2.0", but 2.0 would have the unfortunate
effect of confusing people regarding our .net 2.0 support.
So am thinking that maybe we could call this "Mono 1.5", or if we
plan on keeping the even/odd release numbers from the kernel that we
could call this Mono 1.6 or 1.8
Opinions?
Miguel.
Credo che sia un modo molto democratico di scegliere i numeri della release, anche se a dire il vero non è molto "aziendale". Voi che ne pensate?
Io mi sono espresso per la 1.2