Come architetteresti un'applicazione desktop in C# 3.0

Question

Ho creato una semplice applicazione desktop in C# 3.0 per imparare un po' di C#, wpf e .Net 3.5.La mia applicazione legge essenzialmente i dati da un file CSV e li memorizza in un database CE di SQL Server.Utilizzo sqlmetal per generare il codice ORM per il database.La mia prima iterazione di questa app è brutta da morire e sono in procinto di refactoring.

Il che mi porta alla mia domanda.Come progetteresti un'app di database desktop in C#?Quali sono le migliori pratiche?

Crei un Database Abstraction Layer (DAL) che utilizza il codice generato da sqlmetal?Oppure il codice generato è abbastanza astratto?

Se usi il modello DAL, lo rendi un singleton o un membro statico?Usi il modello View-Model-ModelView con il modello DAL?

Mi scuso se questa sembra una domanda lunga e aperta, ma ci ho pensato molto di recente.Vedo molti esempi su come progettare un'app aziendale a più livelli in C#, ma non così tanti sull'architettura di app desktop autonome.

Answer 1

Inizierei con il Guida all'applicazione composita per WPF (tosse PRISMA tosse) dal team P&P di Microsoft.Con il download arriva un'ottima applicazione di riferimento che rappresenta il punto di partenza per la maggior parte del mio sviluppo WPF oggi.

IL La squadra di DotNetRocks appena intervistato Glen Block E Brian Noyes a questo proposito se sei interessato a saperne di più da loro.

Ancora meglio, Prism non è pesante quanto lo era il CAB, se lo conosci dai tempi di WinForms.

Answer 2

La risposta è "dipende", come sempre.

Alcune cose a cui pensare:Ad un certo punto potresti voler trasformare questa app fat client in un'app Web (ad esempio).In tal caso, dovresti assicurarti di mantenere la separazione tra il livello aziendale (e inferiore) e la presentazione.Il modo più semplice per farlo è assicurarsi che tutte le chiamate alla logica aziendale passino attraverso un'interfaccia di qualche tipo.Un modo più complesso consiste nell'implementare una configurazione MVC completa.

Un'altra cosa che potresti considerare è rendere il livello di accesso ai dati indipendente dalla logica aziendale e dall'interfaccia utente.Con questo intendo che tutte le chiamate dalla logica aziendale al DAL dovrebbero essere generiche "procurami questi dati" anziché "procurami questi dati da SQL" o, peggio ancora, "esegui questa istruzione SQL".In questo modo, puoi sostituire il tuo DAL con uno che accede a un database diverso, a file XML o anche a qualcosa di complicato come i file flat.

In breve, separazione delle preoccupazioni.Ciò ti consente di crescere in futuro aggiungendo un'interfaccia utente diversa, segmentando tutte e tre le aree nel proprio livello o modificando la tecnologia pertinente.

Answer 3

Prima di progettare qualsiasi cosa dovresti definire i requisiti per la tua app.
È un errore comune degli sviluppatori principianti: iniziare a scrivere codice prima di pensare a come funzionerebbe.Il mio consiglio sarà di provare a descrivere alcune funzionalità della tua applicazione.Ti aiuterà a sentire come dovrebbe essere implementato.

Per quanto riguarda le risorse didattiche utili, ti consiglio vivamente di dare un'occhiata WPF composito è un progetto progettato specificamente per insegnare agli sviluppatori le migliori pratiche per lo sviluppo di app desktop.

Answer 4

Inizierei con quello di Jeremy Miller Costruisci la tua cabina serie.

Sono stato uno dei primi ad adottare il CAB.Ho imparato molto approfondendo quella tecnologia e leggendo tutti i blog .NET sull'architettura delle applicazioni.

Ma recentemente ho avuto la possibilità di iniziare un nuovo progetto e invece di utilizzare CAB ho scelto StructureMap e NHibernate e ho preso in prestito alcuni dei pattern utilizzati da Jeremy (in particolare il suo modo di gestire l'aggregazione degli eventi).Il risultato è stato un framework davvero semplificato e realizzato manualmente che fa tutto ciò di cui ho bisogno e adoro lavorarci.

Per quanto riguarda lo specifico della tua domanda:Utilizzo un repository per l'accesso ai dati.Inizialmente ho scritto del codice ADO.NET, utilizzato lettori di dati e mappato i miei oggetti.Ma la cosa è invecchiata molto velocemente, quindi ho preso NHibernate e sono rimasto davvero soddisfatto.I repository utilizzano NHibernate per l'accesso ai dati e le mie esigenze di accesso ai dati sono piuttosto semplici in questa particolare app.

Ho un livello di servizio (esposto tramite WCF, canali Duplex) che utilizza i repository.La mia app è fondamentalmente client-server con aggiornamento in tempo reale (e so che la tua domanda riguardava solo i client, ma utilizzerei le stesse tecnologie e schemi).O

Dal lato client utilizzo MVP con StructureMap per IoC e alcune strategie di aggregazione di eventi molto semplici per comunicazioni tra classi.Codifico le interfacce per quasi tutto.L'unica altra cosa che ho fatto è stata prendere in prestito dal CAB l'idea di uno "spazio di lavoro" flessibile per visualizzare dinamicamente le visualizzazioni.Tuttavia ho scritto la mia interfaccia Workspace e ho implementato il mio DeckWorkspace e TableWorkspace da utilizzare nella mia app (erano cose davvero semplici da scrivere).

Molte delle mie decisioni in questa applicazione più recente sono state il risultato dell'esperienza e del dolore che ho provato utilizzando altri framework e strumenti.Questa volta ho preso decisioni diverse.Forse l'unico modo per capire veramente come progettare un'applicazione è provare in anticipo il dolore di farlo in modo sbagliato.

Answer 5

Direi di sì, potrebbe facilmente essere strutturato verso applicazioni più piccole.C'è una curva di apprendimento per iniziare, ma onestamente mi ha aiutato a capire meglio WPF che tentare di iniziare da zero.Dopo aver avviato un progetto con CompositeWPF e averne avviato un altro senza, mi sono ritrovato a tentare di duplicare da solo le funzionalità di CompositeWPF perché mi mancavano quelle funzionalità!:)