Methods for storing an item in numerous postbacks

asp.net entity-framework postback

Question

Let's say, just for the sake of argument, that I create a webform where a user may update the specifics of an order. The user is able to carry out the following tasks:

  • Modify the shipment or payment information (all basic text or dropdowns)
  • Products may be added, removed, or edited in the order using a grid.
  • Adding/deleting attachments

With a foreign key to the order, additional DB tables are used to hold the products and attachments.

The ORM is Entity Framework (4.0).

I want to give users the freedom to modify the order as they see fit, and I only want to submit the changes to the database when they click "Save." Textboxes, checkboxes, and other similar objects are not an issue since I can simply depend on ViewState to get the necessary data. However, the grid is causing me a far bigger difficulty since I can't find a convenient method to save the user's modifications without also saving them to the database. The Order object tree might get extremely huge, therefore I'm not really interested in storing it in Session/ViewState.

How do I go about keeping the modifications the user made till I'm ready to "Save" is the query, then.

Just a quick note: I scoured SO to attempt to find a solution, but all I saw were recommendations to utilize Sessions and/or ViewState, both of which I would prefer not to use given the possible size of my object trees.

2
5
1/7/2010 9:49:38 PM

Accepted Answer

The best option 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 if using the Session is not your preferred solution, which is probably wise.

2
1/13/2010 9:41:05 PM

Expert Answer

What size do you believe to be large? State is often a fairly decent alternative if you are talking sessions-state (so it doesn't move back/fore to the actual user, like view-state). Serialization is used by everything except the in-process state provider, however you may control whether or not it does so. For instance, I usually build a local model for the operation that reflects the state I'm interested in (plus any id/rowversion information) (rather than the full domain entities, which may have extra overhead).

I would think about utilizing something like protobuf-net, which can be used as the implementation for, to further decrease the serialization cost.ISerializable , permitting light-weight serialized items (often considerably less than zzz-24 zzz)BinaryFormatter , XmlSerializer inexpensive to rebuild at page requests (e.g., etc.).

I would edit my domain entities using the local model when the page was eventually saved, then submit the modifications.

For information, using the state serializers with a protobuf-net attributed objectBinaryFormatter ), you may employ:

// a simple, sessions-state friendly light-weight UI model object
[ProtoContract]
public class MyType {
    [ProtoMember(1)]
    public int Id {get;set;}

    [ProtoMember(2)]
    public string Name {get;set;}

    [ProtoMember(3)]
    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);
    }
}
0
1/16/2010 8:04:48 AM


Related Questions





Related

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