Generic Linq to SQL handler - Update issue RRS feed

  • Question

  • Hi,

    I have implemented a generic handler to all ORM sets in my DAL. This works fine on all CRUD operations except (of course) the U. The attach method doesn't seem to work if you don't have access to the context that you used to retrieve the object. As Im writing an n Tier system, the context go in and out of scope - the app is stateless.

    The method is below

    public bool Update(T item, string pk )


    //clone for scoping reasons

    T t = null;

    t = CloneObject(item, t);

    using (Context)


    Context.GetTable<T>().Attach(item, SelectByPK(pk));



    return true;


    Context is a singleton implementation for returning the context object. The clone method works fine, as does the SelectByPk  - it is not an issue with those.  I can't keep a handle to the datacontext object in every object. Is there a work around for this? Is even using Linq To SQL a good idea in a middle tier n tier system?

    Thanks in advance 

    Friday, January 16, 2009 2:05 AM

All replies

  • Your best option when working in disconnected environments is to use a TimeStamp/RowVersion column in your table and then handle your concurrency that way. If you are using a time stamp, you should be able to use the Context.MyTable.Attach(ChangedObject, true) to perform the update.

    Alternatively, you can fetch the current object (realizing that it may not be the same as when you originally fetched your object and disconnected it) and playback the changes from the changed object in the middle tier and then save that copy.

    Jim Wooley - "LINQ In Action", The book is now available. Don't wait for the movie
    Friday, January 16, 2009 4:27 PM