attending TechEd 2008 in Orlando this past week and speaking recently on this topic at the Austin Code Camp, I have a (what I think) is a better approach to doing data access with LINQ to SQL in an ASP.NET web project. First, it is definitely my preference to separate all data context activity to the business and/or data tiers.

Some key things that I have learned along the way. You will want to use the Attach(entity, true), which essentially tells LINQ to "trust me, the entity has changed, update the whole thing." In order for this to work with an entity that

idual operation. Other ORMs typically have a static DataManager that load, save and otherwise manage entity instances. So you might create a context and load an entity and then modify it. Later you then create another instance and try to save this entity. Other ORMs typically have a method to load an entity and another to save one with a parameter for an entity to save. This approach really doesn't work with LINQ to SQL because of the change information is contained in the DataContext. LINQ to SQL really only has one way to commit updates which is by calling SubmitChanges() that takes all the changes stored on DataContext and writes them to the data store. There's no real way to abort changes eit