<p>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. </p>

<p>For example, using ye olde Northwind database, if I create the dbml with the Products table, a <code>Product</code> 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 <code>Product</code> class, along with every other "model."</p>

<p>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.</p>

Scott Hanselman did a screen talking about asp.net DynamicData where he used Linq To Sql classes.  Although he wasn't addressing the particular issue I think the general concept would still work. His approach was to create a separate
partial
class that had the same name as the class,
```
Product
```
in your case, that was generated by the dbml.  Then you should always have a
```
Product
```
class that exists outside of what LINQ generates and just "extends" what it does.