ObjectDataSource - Object Graphs

microsoft.public.dotnet.framework.aspnet

15 Dec 2005 11:55 PM

David Jessee

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.

16 Dec 2005 12:43 AM

Bruce Barker

that what the object data source is for, your BI object should implement
binding interfaces (get,set,delete) for the ObjectDataSource to use.

-- bruce (sqlwork.com)

Show quote

"David Jessee" <DavidJes***@discussions.microsoft.com> wrote in message
news:A27B3B40-30D4-4772-BBC7-863A3B3D90A3@microsoft.com...
> 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.

16 Dec 2005 3:01 AM

David Jessee

So I hear....
I can see how the ObjectDataSource can interact with a simple class. But how
do you use it with a complex object graph?

for instance....when you execute an update, it (1) creates a new instance of
your business class (2) sets its properties and then (3) passes it off to a
repository class.

but what if I want to use a serialized instance I'm holding in view state
instead of having the data source create a new instance? What if I want to
let the data source feed the input values back into my class, but not save it?

Show quote

"Bruce Barker" wrote:

> that what the object data source is for, your BI object should implement
> binding interfaces (get,set,delete) for the ObjectDataSource to use.
>
> -- bruce (sqlwork.com)
>
>
>
> "David Jessee" <DavidJes***@discussions.microsoft.com> wrote in message
> news:A27B3B40-30D4-4772-BBC7-863A3B3D90A3@microsoft.com...
> > 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.
>
>
>