Ciao, bel quesito... come dice alka non è semplice darti un buon consiglio in quanto entrano in gioco tanti fattori. Diciamo che in linea di massima, secondo la mia personalissima logica, dovresti sviluppare una "dll" (potrebbe anche non esserlo, ma per praticità...) centrale oppure comune a tutti i moduli (o plugin che si voglia), nel primo caso (centrale) intendo dire un qualcosa, come hai detto tu, che gestisce la comunicazione con la serializzazione dei dati (db), oltre a sostenere la validazione di base dei tipi e delle regole assolute, questo modulo non dovrebbe contenere nulla che non sia compatibile con le varie modalità di fruizione dei dati (per intenderci deve poter essere sfruttato sia via web che locale quindi completamente separato dal resto degli strati) e dovrebbe essere facilmente estensibile attraverso l'ereditarietà tipica di NET. Lo stesso modulo, sempre a parere mio, dovrebbe contenere un adattatore di base che fornisce funzionalità intermedie che consentono di avere le classiche funzioni di base esposte per facilitare il binding con le varie interfacce grafiche secondo le varie modalità che ad oggi ci consentono di fruire dei contenuti, per intenderci meglio, poniamo l'esempio di WPF e Silverlight (in particolare quest'ultimo nella versione 5), che con una sorta di adattatore (o ViewModel base) ti consentono di avere uno xaml sostanzialmente uguale per entranbi in modo da poter sfruttare tutta la potenza del motore di binding e traslare tranquillamente tutta l'applicazione (o suddividere in parti) dal web a locale o "desktop" + db remoto (dove possibile), grazie anche alla possibilità di migrare le funzionalità del modello verso servizi web. Ovviamente parlo di Entity Framework di ADO.NET come modello di dati, che nella sua ultima beta (4.3) include anche Entity Migration ottimo da utilizzare per portare il modello verso il web con pocchissimo sforzo (praticamente nullo!), classi POCO Code First con qualche implementazione di interfacce (tipo IValidatableObject sulle classi e IDataErrorInfo, IServiceProvider ecc. sull'adattatore-ViewModel) e un adattatore che fornisce un derivato da se stesso per i dati relazionati (child) sfruttando la reflection e il tipo (diventato per me ormai indispensabile!!!) dynamic in modo da ottenere sia il salvataggio/modifica/eliminazione ecc. sia un modo per poter filtrare i dati con query complesse direttamente nello xaml utilizzando una sintassi semplice tipo : (questo è solo un esempio, ma si possono creare query ben più complesse!)
codice:
{Binding Filters["Cognome.#CONFRONTO*+CONTIENE-:TXTContiene"].AND["Cognome.#CONFRONTO*+INIZIA-:TXTInizia"]}
oppure
{Binding Filters["Cognome.#CONFRONTO*+CONTIENE-:TXTContiene+CASESENSITIVE:TRUE"].OR["Cognome.#CONFRONTO*+INIZIA-:TXTInizia+CASESENSITIVE:FALSE"]}
ecc.
dove Cognome è ad esempio una proprietà di una classe del modello (classe bindata nel datacontext da Adattatore<classe>) e TXTContiene e TXTInizia sono textbox bindate per inserire i valori (inizia e contiene) da confrontare.
A questo punto, non rimane altro che importare la dll in qualsiasi progetto di qualsiasi tipo, e sviluppare ciò che ti serve in aggiunta in modo completamente slegato e senza aggiungere codice per le operazioni base e gestendo tutto dallo xaml attraverso binding dei comandi (ICommand) e dei dati. poi ti fai il tuo bel setup e aggiungi o rimuovi solo ciò che vuoi tu, ad esempio statistiche, operazioni aggiuntive, inserimento di alcuni dati da web ecc. lasciando sempre inalterato il modulo principale. tieni presente che in questo modo nella dll hai sempre i dati completi e aggiornati perchè serializzati in un unico db e disponibili come semplici oggetti (già valorizzati).
considera questo dato :
una volta sviluppato il modulo principale (l'adattatore mi ha richiesto 4 mesi ininterrotti di duro lavoro), ho potuto sviluppare un modulo aggiuntivo per il rilevamento biometrico per una determinata funzione in mezza giornata di lavoro! (ovviamente la parte dell'interfaccia e la gestione, la logica del rilevamento mi aveva portato via in passato circa 2 settimane), e il bello che l'adattatore posso riutilizzarlo con modelli differenti, quindi sostanzialmente con programmi differenti!
oppure puoi usare le classiche interfacce comuni in una dll da importare, il classico metodo del quale trovi descrizioni ovunque nel web... oltretutto ricordo di averne parlato io stesso abbondantemente in un post con un altro utente proprio su questo forum credo nel mese di agosto scorso.
a te la scelta.
il mio consiglio? mmm... mi sa che si capisce!!! 
Rispondi quotando
