Question

I like LINQ to SQL, but it seems like the classes it generates are tightly coupled to the database they are stored in, which seems like a Bad Thing.

For example, using ye olde Northwind database, if I create the dbml with the Products table, a Product class is generated. I can use this class in any other tier, which is all well and good, but if I decide I’d rather use plain old ADO.NET (or switch databases), I’ll have to recreate the Product class, along with every other ‘model.’

Is there a way around this? Or to create your object models separately, and then have the tables mapped to them? I’ve played around with the various mapping classes provided, but haven’t found a satisfactory answer yet.

Answer 1

All these answers and no links! Maybe I can help:

The attributes thing that damieng mentioned

The partial class thing that Marcus King mentioned

I have languished through this difficulty a couple of times, what I ended up doing on my last project was using interfaces as the contract that’s shared between all of the different projects in the solution, and having the partial classes implement it.

[Table(Name='Products')] public partial class Product: IProduct { } 

And yes, unfortunately it took some reflection magic to make it work for the POCO implementation.

In the end, if you are truly concerned about it, I’d go with NHibernate (I don’t really like it either), which does exactly what Garry Shulter seems to be describing.

Hope that helps!