Domanda di architettura per lo sviluppo a livello.

Question

Ciao a tutti sono abbastanza nuovo per il processo di sviluppo a più livelli. Attualmente sto sviluppando un'applicazione e ho alcune domande di base sulle migliori pratiche/domande di architettura con la tecnologia di oggi. Utilizzerò WCF come livello di servizio. Nota sto provando a disaccoppiare le cose il più possibile. Non voglio che nulla ai livelli superiori debba sapere nulla sui livelli inferiori, che è uno dei motivi per cui LINQ TO SQL o il framework delle entità non mi piacciono.

1) Qual è il modo migliore per passare i dati tra i livelli? So che sia un dataset o un datatable sarebbe facile, ma non penserei che passare questa struttura di dati gonfio tra i livelli sarebbe la soluzione migliore. Anche il debugging sarebbe più difficile se i datatables/dataset fossero grandi. Forse una serie di oggetti POCO sarebbe la soluzione migliore o c'è un modo migliore?

2) La prossima domanda è un po 'più complicata. Molte applicazioni avranno un sacco di diverse visualizzazioni dei dati. Potresti avere più report, una varietà di datagrids e magari un grafico o due. Come procedi nel progettare il tuo livello dati per questo? Disegnate semplicemente una funzione di tipo "Ottieni" per ogni tabella e poi provate a combinarli in viste utili per dire una griglia o un report nel vostro livello commerciale o avete una funzione specializzata per ogni vista di cui avete bisogno nel livello commerciale.

A dire il vero non mi piace nessuna delle due soluzioni. Se si decide la logica specializzata per visualizzazione, sarà necessario creare un oggetto POCO (presupponendo che si restituisca un array di oggetti POCO) per visualizzazione. Se in seguito decidi di aggiungere più colonne a una vista, spezzerai il codice esistente (perché cambi l'interfaccia su POCO). Se decidi di restituire una vista di ogni tabella e provare a combinarla nel livello commerciale di quello che potrebbe diventare DAVVERO disordinato. TSQL si unisce per un motivo :). Inoltre potresti restituire molti più dati di cui hai bisogno a seconda del tuo design che sarebbe inefficiente.

Ho qualche altra domanda ma la salverò più tardi. Non voglio questo post per diventare a grandi :)

NCAGE

Answer 1

penso che ti manca un po 'con l'idea di non voler il livello dati di sapere nulla di livello aziendale o di interfaccia utente. In uno strumento ORM (LINQ to SQL, ad esempio), le proprietà delle entità sono determinate dai dati. Non c'è davvero nessuna ragione per non farlo. Avere entità fortemente tipizzate non è la stessa di avere una logica aziendale/UI nel livello dati ed è generalmente una buona cosa; come ci si arriva dipende da voi.

Io sostengo SEMPRE l'utilizzo di un componente fortemente tipizzato per trasmettere dati in contrapposizione a un repository generico come un DataSet/Table/Row/View/etc.

Forse potresti ampliare un po 'ciò che ti ha allontanato da questo approccio?

Answer 2

Queste sono domande molto buone. Ci sono molte possibili risposte e molte possibili architetture. Ti raccomando di leggere un primer sull'argomento. Patterns & Practices has a very good one. È gratuito, completo e discute in profondità le domande che stai facendo. Nessuna guida all'architettura è perfetta, ma come punto di partenza, non penso che tu possa sbagliare studiando le basi.

Answer 3

Buone domande. Cose importanti, questo. In generale, uno dei modi migliori per approcciare le soluzioni a più livelli è guardare le interfacce. Le interfacce sono un modo per fornire "chokepoints", che possono servire a diversi scopi utili.

All'interno di soluzioni a livelli, le interfacce servono a rafforzare i comportamenti dei livelli; efficacemente definendo l'insieme di comportamenti che ci si aspetta, si disaccoppia l'implementazione dei livelli.Cioè, fintanto che il mio livello implementa correttamente l'interfaccia, l'implementazione è qualcosa che non mi interessa affatto.

L'ho portato in su (ed è pertinente) perché quando si definiscono le proprie interfacce, è anche necessario definire i dati che vengono passati tra i livelli. Quindi, quando si definisce cosa deve accadere tra i livelli, si finisce per definire quali dati vengono passati; e allo stesso tempo, definire un set di dati rigido che viene passato.

Un punto rilevante qui relativo alla segregazione è che nessuna informazione sull'implementazione di un livello deve essere passata tra i livelli. Cioè, definendo la tua interfaccia ed essendo rigoroso sull'implementazione, dovresti essere in grado di renderlo tale che l'implementazione del tier possa essere reimplementata da zero, conoscendo solo l'interfaccia, e possa sostituire l'altra implementazione senza problemi.

Sapere questo rende le cose semplici; usando Plain Old Objects generalmente manterrai le tue interfacce pulite e corrette; e mantiene le tue strutture dati da gonfiarsi. Serve anche a prevenire la tentazione di utilizzare alcune informazioni sull'implementazione di un livello in un altro livello.

Naturalmente, per fare ciò correttamente, è utile avere una visione lunga del problema da risolvere; quali sono le serie di operazioni che l'utente vorrà fare? Queste operazioni generalmente si risolvono in "verbi" che si adattano bene alle definizioni dell'interfaccia che definiscono il contratto che gli oggetti aziendali implementeranno. I set di dati su cui opereranno i tuoi oggetti business definiranno l'insieme di viste che devi avere sul tuo database. In questo modo, puoi mantenere in modo pulito la tua separazione.