Buona architettura per desktop 2-client (client-server) utilizzando linq-to-sql

Question

La nostra architettura attuale - UI, BusinessLayer, DAL (linq-to-sql generati). Nel livello DAL, abbiamo aggiunto la logica di validazione per entità in classe parziale. Utilizziamo direttamente le entità generate da linq-to-sql in businesslayer (che è un mucchio di classi - class \ form). Inoltre, in queste classi bll, creiamo query linq-to-sql.

Penso che potremmo stratificare l'applicazione meglio in termini di pattern MVP e avere classi di servizio che forniscono dati usando linq-to-sql. Cosa ne pensi? Dovrei considerare il pattern del repository? Sarebbe eccessivo?

Answer 1

È una buona idea!

tua scelta dipende dalla vostra applicazione, ma questi sono molti problemi:

1) La trasformazione tra il modello oggetto di database e l'applicazione del modello a oggetti può essere molto più difficile. In tali casi, è impossibile implementare i filtri su un modello per l'applicazione in modo che la query risultante possa essere trasmessa in SQL.

2) Spesso, come risultato di campionamento necessaria per ottenere il risultato della connessione (JOIN) più tabelle, e non solo i dati di una tabella

3) Non tutti SQL-operazioni e funzioni hanno il loro equivalente in LINQ

Che dire di Entity Framework? Per favore, non toccare Entity Framework. È una cosa pesante e lenta! :)

Preferisco l'accesso ai dati classici tramite il proc memorizzato e l'accesso ai dati dalla MS Enterprise Library. Posso usare la potenza di SQL e la flessibilità delle mie entità aziendali. E ovviamente - prestazioni! Il rovescio della medaglia è più lavoro. Ho usato alcuni strumenti per generare automaticamente gli oggetti di accesso ai dati e quindi correggerli quando necessario.

Fortuna!

Answer 2

Tutte cose buone a cui pensare, ma quando inizi questa strada sono sicuro che avrai più domande che risposte molte volte!

Suppongo che tu stia utilizzando Windows Form quando menzioni Desktop e Linq-To-SQL, che ti daranno alcune sfide nell'implementare qualcosa come un pattern MVP.

Mentre ci sono framework MVP pre-adattati per WinForms (mi viene in mente MVC#), se non stai sviluppando app su larga scala, potresti iniziare con delicatezza e implementare alcuni concetti usando il tuo codice.

L'eccellente serie di articoli Build Your Own CAB di Jeremy Miller è un'ottima risorsa qui, poiché puoi prendere alcune delle prime idee da lì e ottenere una separazione delle preoccupazioni tra le tue forme (Presentazione) e la logica aziendale (Presentatori e Classi di servizio).

Jeremy utilizza principalmente un progetto di Controller di supervisione nel suo lavoro (che adoro), ma vale la pena guardare ad altri modelli come Passive View e Model-View-ViewModel (che è inserito nel modo di lavorare WPF, quindi vale la pena comprensione), per vedere cosa ti senti più a tuo agio.

Per quanto riguarda la tua domanda sulle classi di servizio o sui repository, penserei che i due principali livelli di logica che desideri siano Presenter o ViewModel e quindi Entità di servizio al di sotto di ciò che può contenere cose come il tuo Linq-To- Query SQL.Quindi potresti già avere molta della logica per il tuo livello di servizio, ma è più un caso di refactoring in una forma coerente.

Answer 3

Sembra che tu sia sulla strada giusta. Se si disponesse di un livello di servizio WCF, è possibile eseguirlo in corso o tramite HTTP, il che significa che è possibile supportare un'applicazione di tipo server client piuttosto che colpire il DB dal front-end, ma in realtà dipende dall'applicazione.

Answer 4

MVP può essere difficile da capire per gli sviluppatori, ma potresti provarlo.