Utilizzando il designer le vostre classi di accesso ai dati conterranno una serie di attributi necessari affinche Linq to Sql possa gestire le operazioni di persistenza dei dati.
Se non amate gli attributi e preferite invece file di mapping xml la soluzione è utilizzare l'utility SqlMetal.exe fornita con visual studio, che vi permette di generare tutte le classi per un intero database. Ecco ad esempio come generare tutto il dominio per il database NorthWind
sqlmetal /server:LAPTOPVM1SQLEXPRESS /database:northwind /map:NorthwindVer1.map /code:NorthwindVer1.cs
La sintassi è veramente facile, basta infatti specificare il nome del server, il database ed i nomi dei file da generare, uno (il punto map) contiene il mapping, mentre l'altro contiene il codice di tutte le classi. A questo punto basta includere il file .cs nella propria solution ed il gioco e chiamare il costruttore del DataContext passando manualmente il MappingSource
Northwind database = new Northwind(
"server=LAPTOPVM1\\SQLEXPRESS;Database=Northwind;Integrated Security=SSPI",
XmlMappingSource.FromUrl( "NorthwindVer1.map"));
La classe XmlMappingSource del namespace System.Linq.Data.Mapping permette infatti di generare l'oggetto MappingSource dal file di mapping, mentre nel DataContext generato con il designer si trova questa riga
private static System.Data.Linq.Mapping.MappingSource mappingSource =
new AttributeMappingSource();
che mostra chiaramente come in questo caso il MappingSource venga generato dagli attributi delle classi. Se si controllano le classi generate dal SQLMetal con l'opzione map attiva si nota che non sono più presenti gli attributi per il mapping.
Quale delle due soluzioni adottare è questione di gusto personale, ma per chi come me viene da NHibernate avere il file di mapping può essere interessante.
alk.