I have a parent Resource object and that Resource oject has a child WorkDetails object, on my WebForms I just want to bind my Resource object to DetailsView Control to to my data manipulation, the thing is how will i get the values off that WorkDetails child object to display off to my DetailsView Control?
Having this model I dont have to add a new CslaDatasource to my webpage to cater the insert/save of my workdetails object right? because its a child object and it should be handled by its parent right? If anyone can confirm my understand around this thought i would greatly appreciate it.
You need a CslaDataSource control for each different business object type. This is because the web forms designer uses the datasource control to get the "shape" of the object.
Your "child datasource" object's SelectObject event handler can just set e.BusinessObject to the child property of the parent business object.
Thanks for your reply Rocky, that’s was my initial thought too, but I saw this code on the sample PTracker on the Resource class on the DataPorta_Insert() you got a to .UpdateChildren(this), it makes me think that I can use the resource obj to insert an object together with its child. Can you please explain this a bit more…
Data binding at the UI level has nothing to do with data access.
Object graphs are loaded and saved as a unit, with exactly one root object that may contain child objects. Read or reread chapters 1-5 of the Expert 2008 Business Objects book to get a firm grasp on the related concepts.
Binding these objects to the UI is different depending on your UI technology. In Web Forms you typically do this using a CslaDataSource control for each business type. Only the root type can be retrieved or saved directly of course - but you still need to use a data source control for child types so data binding knows how to interact with the type.
Create/update/delete handlers for a child type typically don't actually interact with the data portal of course, because you can't directly save a child object. Instead, those operations typically interact with the existing object graph (normally stored in Session).
If you want to have a stateless web server (no Session) that's fine - but you'll need to think about your object model design differently. In a stateless web world, there typically are no child objects - only root objects. This is because every postback operates on a single object that is immediately retrieved/stored. This type of object model is less elegant, and requires more explicit code, but it is the cost you pay to get an efficient stateless model.
A less efficient alternative that is still stateless is to re-retrieve the object graph on every postback. And that can work for very small apps with few users, but it is not a good overall solution in most cases.
In short, are you stateful or stateless?
ProjectTracker is stateful - it uses Session - which is a reasonably efficient model and is the easiest model (because you can construct "normal" object designs).
If you are stateless, then you will either have only root objects, or you'll reload the object graph to do a save.
Thank you for this very concise explanation Rocky, appreciate it deeply.
Copyright (c) Marimer LLC