Migliori pratiche:Architettura a tre livelli in LINQ

Question

Sto lavorando a un progetto personale (C#/ASP.NET) che utilizzerà LINQ to SQL.La soluzione avrà (finora) un progetto Webform, un progetto Namespace (logica aziendale) e un progetto Tests.Finora sono nelle primissime fasi (chiaramente in fase di progettazione).

Esiste un paradigma per l'architettura a 3 livelli qui?Sembra che il DAL sia del tutto inutile in questo caso;mi sembra che dovrei eseguire la query LINQ direttamente dalla logica aziendale.

Mi viene anche in mente che se tenessi solo un DataContext residente e lo passassi in giro, avrei bisogno solo di una connessione aperta.Ciò avrebbe l'ulteriore vantaggio di applicare le modifiche tutte in una volta anziché in modo granulare.Qualche idea a riguardo?

ho trovato questo filo, ma sembra dipingere un quadro incompleto.Ci sono articoli approfonditi sull'argomento?

Answer 1

Puoi pensare a LINQ-to-SQL come il tuo DAL, quindi usalo " direttamente dalla logica di business " non è necessariamente una cosa negativa.

http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-in-linq.aspx ha alcuni approcci L2S popolari elencati .

Nel nostro progetto, non volevamo passare il contesto dei dati, quindi abbiamo usato un modello simile al n. 3 dal link sopra (Ambient DataContext, vedi sotto). Aveva alcuni problemi, ma funzionava abbastanza bene; almeno per il nostro progetto web.

  

Ambient DataContext (attualmente in uso)

     

L'idea alla base di datacontext ambientale è che il contesto viene creato per un thread specifico o un httpcontext (in asp.net) non appena viene effettuata una prima chiamata per DataContext. Quindi lo stesso contesto viene utilizzato per quel thread o richiesta a meno che non venga eliminato manualmente. Questo viene fatto memorizzando il contesto nell'archivio dati di richiesta / thread. L'approccio a questo modello è simile a DataContext statico, tuttavia, viene fornita la separazione per ogni thread e richieste. Questo funziona davvero bene in Asp.Net, tuttavia, è di nuovo afflitto da alcuni dei problemi del contesto statico.

     

Problemi con questo modello:

* The context is available for manipulation at any level. And quickly becomes very hard to maintain unit of work
* Portability across thread is very hard
* Unit of work pattern is not transparent enough

Answer 2

Potresti leggere un po 'su Domain Driven Design.

Con la pratica di Domain Driven Design (DDD), hai un ricco "modello di dominio", in cui esprimi il dominio problematico che vuoi affrontare. Questo modello di dominio è costituito da classi (e strutture) con cui modellare le entità aziendali. Il modello di dominio comprende anche repository.
Un repository è una sorta di astrazione che usi nel tuo modello di dominio (e nella tua applicazione); Il repository è un'astrazione del tuo archivio dati. Tramite il repository, è possibile recuperare entità e utilizzare il repository per conservare le entità.

Nel tuo caso, i tuoi repository potrebbero usare Linq To SQL internamente per parlare con il database. Si noti tuttavia che il repository non dovrebbe essere responsabile della gestione (apertura / chiusura) della connessione e della transazione (avvio / commit / rollback). Perché ? - gt &; perché il repository non ha alcuna conoscenza o nozione del contesto in cui viene utilizzato. È il tuo livello di applicazione o servizio (il livello che utilizza il tuo modello di dominio e quindi il tuo repository) che dovrebbe essere responsabile dell'apertura di una nuova connessione e dell'avvio / commit delle transazioni. (O nel tuo caso, apri un nuovo DataContext). È quindi possibile passare DataContext al repository.

(Eric Evans ha un grande libro su DDD, anche se di tanto in tanto da rompere, di volta in volta).

Answer 3

Dovresti stare attento con la tua terminologia. Quando dici LINQ intendi Linq-to-sql e quando dici a 3 livelli ciò significa di solito che stai parlando di uno scenario di distribuzione con 3 macchine separate. Non sono sicuro che sia questo che intendi.

Un'architettura a tre livelli è ancora una buona idea quando si utilizza uno strumento ORM come linq-to-sql. Il DAL diventa solo un luogo in cui archiviare la logica della query. È una buona idea eliminare le query dal livello aziendale perché le query rappresentano un problema di persistenza, non un problema di logica aziendale.

La consueta tecnica per gestire il contesto dei dati è di avere un singolo contesto di dati per richiesta.

In termini di altri articoli sull'argomento, puoi consultare qualsiasi guida sull'architettura per qualsiasi strumento ORM: linq-to-sql non è diverso. Cerca articoli sull'architettura di NHibernate.

Answer 4

La libreria LINQ to SQL è il tuo DAL in questo caso e invece di effettuare chiamate API tradizionali dal tuo livello aziendale (ad es.DAL.GetObjectById(id)) hai la flessibilità di richieste molto più espressive nel DAL.

Se avessi altre esigenze, ad esempio il tuo provider LINQ che si connette a un supporto dati non MSSQL, implementeresti il ​​tuo DAL.

Inoltre, per quanto riguarda DataContext, non è consigliabile utilizzare un modello singleton con "un DataContext residente".Un oggetto DataContext dovrebbe rappresentare una singola transazione logica, qualunque cosa ciò significhi per la tua applicazione.(Parafrasato da http://weblogs.asp.net/despos/archive/2008/03/19/more-on-datacontext-in-hopefully-a-realistic-world.aspx)