I see a number of posts talk about rolling your own LINQ to SQL XML mapping file. Why would you do this instead of using SQLMetal or the designer built into studio? Is it because you want to work with your own POCOs?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I see a number of posts talk about rolling your own LINQ to SQL XML mapping file. Why would you do this instead of using SQLMetal or the designer built into studio? Is it because you want to work with your own POCOs?
If you use the designer then you have no control over the generated classes. While this may be alright for many applications, it’s not appropriate for all.
Probably the biggest single advantage to using an external mapping is that it breaks your model’s dependency on Linq to SQL, so you could (for example) take the exact same model classes and use them with Entity Framework or NHibernate. Projects or assemblies which need to use the model don’t pick up an unwanted dependency on the
System.Data.Linqassembly.Other things you might want to do are:
None of these things are possible with generated code. You can extend via partial classes, but that only lets you add members, not change existing ones. You can change the designer-generated code, obviously, but your changes will just get overwritten.
As I mentioned, many projects don’t need these things, but many projects do, and if yours is one that does then you’ll outgrow the DBML designer and SqlMetal pretty quickly.