Linq to SQL e partizionamento logico (DAL, BLL)

Question

Stiamo per ricostruire uno dei nostri siti in .Net. Ho letto molti articoli e mi piace molto l'idea di separare il nostro progetto in un livello di accesso ai dati (DAL), Business logic layer (BLL) e livello di presentazione (stiamo venendo da ASP classico, quindi questo è un grande passo per noi). Mi piace molto anche Linq to SQL.

Poiché Linq to SQL è mirato allo sviluppo rapido, è davvero possibile con Linq to SQL avere un livello DAL, BLL e di presentazione? Con Linq to SQL il DAL restituisce le entità o il codice linq che potrebbe essere eventualmente modificato nella BLL? La relazione tra DAL e BLL con Linq per SQL sembra essere un argomento sfocato senza alcun consenso - e poiché questo è un grande salto per noi, voglio assolutamente avere un buon piano di gioco prima di tuffarmi in qualcosa.

I set di dati digitati sembrano più attrezzati per questo, ma se riesco a ottenere qualcosa di simile con Linq, vorrei seguire questa strada.

Mi piacerebbe stare lontano da nibernate e altre librerie di terze parti.

Answer 1

Stiamo costruendo esattamente quello che hai descritto e stiamo utilizzando L2S per farlo. Concordato che la relazione tra DAL e BLL è un po 'sfocata, ma abbiamo un BLL distinto e un DAL distinto. Tutta la nostra logica è nella BLL e tutte le operazioni di recupero/modifica dei dati avvengono tramite chiamate al DAL (tramite chiamate LINQ).

La nostra app non utilizza set di dati digitati. Abbiamo creato classi di entità per rappresentare i nostri oggetti. Ora che ho passato un paio di mesi a costruire parte di questo, non vedo che io (io) tornassi mai ai set di dati.

Inoltre, non sarei impiccato a L2S essendo "finalizzato allo sviluppo rapido". Questo fa sembrare uno strumento di prototipazione. Lo stiamo trovando uno strumento di forza industriale. Questo potrebbe essere contrario a ciò che Microsoft potrebbe dire ora a riguardo, dal momento che preferirebbero che le persone usassero EF.

Randy

Answer 2

vi consiglio di fare un passo indietro e guardare le vostre esigenze, ancora una volta.

Avete bisogno di 3 livelli reali (ovvero la distribuzione fisica su macchine diverse) o solo il partizionamento logico dell'applicazione?

Ho fatto esattamente questo errore sulla prima grande applicazione che ho scritto. Non ho mai avuto bisogno di 3 livelli fisici (e non avrò mai bisogno), ma ho progettato l'applicazione in questo modo. La conseguenza più sorprendente è che I Linq2Sql non supporta Rilevamento modifiche disconnesso sulle entità. Ho usato Linq2Sql Entity Base per risolvere questo limite, ma viola molto il concetto di Persistenza Ignoranza (uno sa sempre meglio dopo, eh?).

Il passaggio a livelli n veri ha un sacco di altre implicazioni sull'architettura dell'applicazione.

È necessario inviare messaggi, trasferire dati, ecc. Linq2SQL è un ORM decente, la stretta integrazione con LINQ offre possibilità uniche. Altri ORM avranno ancora bisogno di tempo per raggiungerlo qui. NHibernate 3.0 è una luce alla fine del tunnel qui. Linq2SQL è un ottimo ORM se si dispone di modelli di dati semplici e può essere mappato in modalità "classe per tabella".

Per il rilevamento delle modifiche disconnesse (di cui avrete bisogno se state passando ad altri livelli), altri ORM hanno un supporto migliore.

E infine:

(stiamo venendo da ASP classico quindi questo è un passo enorme per noi)

In queste circostanze mi piacerebbe essere particolarmente attenta. Le tecnologie di commutazione sono spesso sottovalutate. Anche i programmatori più intelligenti del tuo team prenderanno decisioni sbagliate perché non hanno esperienza con la tecnologia. Tuttavia, è importante andare in nuovi modi e migliorare il proprio set di abilità. Coloro che non falliscono mai non potranno mai superare.

Answer 3

IMHO, LINQ to SQL è la scelta migliore attualmente disponibile. Rende davvero il lavoro con i dati indolore e quasi divertente. :-) Se sei interessato a LINQ to SQL, darei un'occhiata al nostro progetto PLINQO. Ha alcuni grandi miglioramenti a LINQ to SQL per renderlo una soluzione globale migliore.

Answer 4

Direi che L2S è il DAL. La logica di business L2S + in classi separate diventa un DAL + BLL unito, il lato DAL è il runtime L2S e il codice generato da L2S (datacontext, classi di entità, ecc.).

È ancora possibile separarli facilmente in modo che la parte generata da L2S e le eventuali estensioni delle entità e del datacontext siano in una DLL separata e una logica di business aggiuntiva in una dll/servizio/ecc. Tuttavia in molti casi non è necessario separarli.

Un motivo per separare DAL + BLL quando si utilizza L2S sarebbe se si prevede di passare a un'altra tecnologia di accesso ai dati lungo la strada o se si sta utilizzando più di una tecnologia di accesso ai dati. Avere un DAL separato con qualsiasi materiale specifico per L2S separato dovrebbe rendere più facile la rimozione del DAL. Se si desidera separare DAL + BLL per questo motivo, la DAL-DLL L2S dovrebbe esporre le classi entità, eventuali classi derivate o classi di proiezione e metodi per ottenere entità o raccolte (Elenco, ecc.), Ma mantenere DataContext interno al DAL classe per evitare di avere cose specifiche di L2S (query L2S, ecc.) che gocciolano nella BLL.

JMHO.

---

Dal altri menzionati L2S strumenti, qui è una sintesi più completa di ciò che è là fuori: http://www.thinqlinq.com/post.aspx/title/linq-tools

Answer 5

penso che con LINQ il DAL e BLL concetti non sono più significativi. Quindi ho inserito classi linq e alcuni getters & setter nella cartella 'Dominio' nella cartella Codice (genitore). Poi ho creato le classi 'Repository' e le classi 'FontEnd'.