G
Guest
I've been taking this approach when working with business entity objects:
1) Determine the ID of the object you need to work with (e.g. Invoice)
2) Get the Object instance of the Invoice...has a Buyer property, which is
an account class...a seller property which is also an accoutn
class....LineItems Collection which contains a number of different classes
that all implement the iLineItem interface).
3) Serialize the object into the viewstate/file system/session/profile
(depending on requirements).
4) Load different UserControls as the user naviagtes the object graph
(EditBuyer/EditSeller loads the AccountEditor control, EditLineItem loads the
appropriate control for the type of line item being edited).
<<note: no changes are persisted to the datastore...just to the object
instance>>
5) after all of the changes are made...accounts modified, line items added
& removed, I tell my persistence layer to save the object and it takes care
of all of the modifications to the different tables.
I've grown very attached to this approach because I end up with the
following advantages
1) nothing's saved until its time to save (how many times have people saved
a header record without any detail)
2) since the instance is serializable, I can Push/Peek/Pop instances on a
stack collection so that I can undo changes.
3) A lot of times, there are rules that have to be validated on an entire
object graph and you end up having to do some tricky things on the database
side if you never know when the object is "really" being saved versus an
intermediate save (yet again....an invoice without line items)
.....so....here's my thought.....
I know I can use the ObjectDataSource to wrap my query classes that return
immutable arrays of results (e.g. InvoiceHeaderSummary). But is there
anything in the ASP 2.0 Binding controls that I can use to edit a complex
object graph?
I get the feeling I'm going to end up having to continue loading
UserControls, depending on the piece of my object graph that needs to be
edited...but I'd love to fine something a little more automated.
1) Determine the ID of the object you need to work with (e.g. Invoice)
2) Get the Object instance of the Invoice...has a Buyer property, which is
an account class...a seller property which is also an accoutn
class....LineItems Collection which contains a number of different classes
that all implement the iLineItem interface).
3) Serialize the object into the viewstate/file system/session/profile
(depending on requirements).
4) Load different UserControls as the user naviagtes the object graph
(EditBuyer/EditSeller loads the AccountEditor control, EditLineItem loads the
appropriate control for the type of line item being edited).
<<note: no changes are persisted to the datastore...just to the object
instance>>
5) after all of the changes are made...accounts modified, line items added
& removed, I tell my persistence layer to save the object and it takes care
of all of the modifications to the different tables.
I've grown very attached to this approach because I end up with the
following advantages
1) nothing's saved until its time to save (how many times have people saved
a header record without any detail)
2) since the instance is serializable, I can Push/Peek/Pop instances on a
stack collection so that I can undo changes.
3) A lot of times, there are rules that have to be validated on an entire
object graph and you end up having to do some tricky things on the database
side if you never know when the object is "really" being saved versus an
intermediate save (yet again....an invoice without line items)
.....so....here's my thought.....
I know I can use the ObjectDataSource to wrap my query classes that return
immutable arrays of results (e.g. InvoiceHeaderSummary). But is there
anything in the ASP 2.0 Binding controls that I can use to edit a complex
object graph?
I get the feeling I'm going to end up having to continue loading
UserControls, depending on the piece of my object graph that needs to be
edited...but I'd love to fine something a little more automated.