LINQ to SQL Classes
LINQ to SQL generates business objects that work similar to datasets. There are some upsides and downsides to that, but overall, I like the approach. LINQ to SQL creates these classes all in the same namespace, so if you have the same object in multiple LINQ-to-SQL class designers in the same namespace, you will get an error in this respect. The best approach may be to create one massive data model for your entire database. Though this may seem like a problem, LINQ can solve this by using a deferred loading approach.
This means that table data loads when you access it. However, all the data loads into that table (but not into respective child tables unless you set it up to load immediately) because LINQ needs the entire data set to query against it. This often puts people on edge about the usefulness of it from the get-go.
However, it's nice because LINQ manages its state for you, and manages all the relationships between objects. It also can have individual properties be lazy loaded (such as loading raw data). And, the designer manages all the relationships between entities, and each relationship is setup as a parent/child collection approach, so the parent object can have immediate (yet lazy loaded) access to its children.
All in all, it is a good idea, though for those who love to have control over their data model, it may not be the most ideal. Something like LINQ to Entities, which should be released this month or the beginning of February, may be a better approach.