Methods for storing an item in numerous postbacks entity-framework postback


For the sake of argument assume that I have a webform that allows a user to edit order details. User can perform the following functions:

  • Change shipping/payment details (all simple text/dropdowns)
  • Add/Remove/Edit products in the order - this is done with a grid
  • Add/Remove attachments

Products and attachments are stored in separate DB tables with foreign key to the order.

Entity Framework (4.0) is used as ORM.

I want to allow the users to make whatever changes they want to the order and only when they hit 'Save' do I want to commit the changes to the database. This is not a problem with textboxes/checkboxes etc. as I can just rely on ViewState to get the required information. However the grid is presenting a much larger problem for me as I can't figure out a nice and easy way to persist the changes the user made without committing the changes to the database. Storing the Order object tree in Session/ViewState is not really an option I'd like to go with as the objects could get very large.

So the question is - how can I go about preserving the changes the user made until ready to 'Save'.

Quick note - I have searched SO to try to find a solution, however all I found were suggestions to use Session and/or ViewState - both of which I would rather not use due to potential size of my object trees

1/7/2010 9:49:38 PM

Accepted Answer

If using the Session is not your preferred solution, which is probably wise, the best possible solution would be to create your own temporary database tables (or as others have mentioned, add a temporary flag to your existing database tables) and persist the data there, storing a single identifier in the Session (or in a cookie) for later retrieval.

1/13/2010 9:41:05 PM

Expert Answer

How large do you consider large? If you are talking sessions-state (so it doesn't go back/fore to the actual user, like view-state) then state is often a pretty good option. Everything except the in-process state provider uses serialization, but you can influence how it is serialized. For example, I would tend to create a local model that represents just the state I care about (plus any id/rowversion information) for that operation (rather than the full domain entities, which may have extra overhead).

To reduce the serialization overhead further, I would consider using something like protobuf-net; this can be used as the implementation for ISerializable, allowing very light-weight serialized objects (generally much smaller than BinaryFormatter, XmlSerializer, etc), that are cheap to reconstruct at page requests.

When the page is finally saved, I would update my domain entities from the local model and submit the changes.

For info, to use a protobuf-net attributed object with the state serializers (typically BinaryFormatter), you can use:

// a simple, sessions-state friendly light-weight UI model object
public class MyType {
    public int Id {get;set;}

    public string Name {get;set;}

    public double Value {get;set;}
    // etc

    void ISerializable.GetObjectData(
        SerializationInfo info,StreamingContext context)
        Serializer.Serialize(info, this);

    public MyType() {} // default constructor

    protected MyType(SerializationInfo info, StreamingContext context)
        Serializer.Merge(info, this);
1/16/2010 8:04:48 AM

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow