Gli oggetti Business Logic devono avere conoscenza dei propri oggetti dati LINQ-to-SQL?

Question

Ho esaminato diverse domande simili ma non ho visto nessuna di quelle che mi riguardavano direttamente, quindi perdonami se questo è un duplicato.

Per separazione delle preoccupazioni, sto cercando di mappare in qualche modo i miei oggetti business con la logica sugli oggetti dati LINQ to SQL nel file .dbml (abbastanza nuovo in questo btw). Ciò che sembra però è che i miei oggetti business dovranno conoscere gli oggetti LINQ2SQL corrispondenti. Ho letto questo articolo su come provare a usare i POCO usando un file di mapping xml, e sembra che sia simile a quello che voglio, tranne per il fatto che non ho un mapping uno a uno dalle tabelle alle classi a causa di una relazione molti-a-molti per la quale avevo bisogno di creare una tabella extra.

Posso incapsulare abbastanza bene l'accesso ai dati nella mia logica aziendale in modo tale che il codice che utilizza i miei oggetti business non abbia bisogno di sapere nulla sul database che sia buono, ma il livello aziendale è ancora strettamente accoppiato con l'accesso ai dati livello tale da non poter sostituire il DAL senza cambiare gli oggetti del mio livello aziendale o crearne di nuovi (che implementano le stesse interfacce) per diversi fornitori di dati.

Come posso disaccoppiare questi livelli?

Answer 1

Non sono sicuro che tu sia legato in qualche modo a LINQ to SQL, ma quello che stai cercando di realizzare è praticamente l'impostazione predefinita in NHibernate. Consiglio di dare un'occhiata a NHibernate per vedere se sarebbe più facile cambiare che combattere LINQ to SQL.

Ho scoperto che combattere uno strumento è quasi sempre una cattiva idea.