What causes the CslaDataSource.SelectObject event to fire?
I have a list that displays products to edit, and when I select a product from the list I want the my CslaDataSource (cdsProduct) to load that product into my DetailsView (dvProduct).
One thing that works is to put "dvProduct.DataBind()" in the "lstProductList_SelectedIndexChanged", which causes the SelectObject event to fire and load the dataview. However, I don't see anything manual like this in the ProjectTracker 2.0 sample project.
Jordan
The way Web Forms data binding works is that the UI control (grid, etc.) decides it needs data. It asks data binding for the data, and data binding asks the data control. The CslaDataSource control, when it gets this request, raises the SelectObject event.
But the whole thing starts with the UI control deciding that it needs data.
The UI controls decide this when the page loads, if they don't already have data. Or if you explicitly call their DataBind() method (because that invalidates any data they have and forces the control to re-request its data).
Rocky,
I'm just getting into 2005 and spent the last week coming to terms with the limitations of the ObjectDataSource. My emotions were typical from what I've read: first excited at the idea of codeless two way binding, then distraught when I realized I would have to dumb down my self-sufficient / intellegent business objects!
Yesterday was my last day of trying to find a way to let the ObjectDataSource use a BusinessObject from Session with read only propeties (yes, I'm slow on the uptake sometimes, and I have to learn the hard way). Today it only took me an hour or so to get your CslaDataSource working flawlessly! I love the four CRUD events that allow us to wire up our objects however we want; it allows for very concise coding. You've saved me from having to compromise the integrity of my BusinessObjects!
Microsoft wants to champion their datasets as the obvious choice. The ObjectDataSource to an OO programmer is nothing but a scarecrow. It's real intentions seem to be for n-tier applications that still use DataSets and a service layer. My main concern now is that the majority of .NET OOP developers (not counting CSLA users) will be lured into using the DataSet / ObjectDataSource paradigm just so they can get enjoy the benefits of the oh-so-appealing codeless two way binding. Then when I join new teams I will be forced to use DataSets! Microsoft is definitely myopic on this issue, and they are incentivizing developers in a direction that a lot of us don't want to go. It's really made me consider moving to Java, where OOP seems to be the center design tenet.
I know this post is a rehash of what the regulars on this forum already know, but I wanted to share my excitement and relief!
- jordan
I'm glad you are finding it useful!
I wouldn't worry too much about Microsoft's "committment" to the DataSet. If you look at what they are doing with .NET 3.5 (ADO.NET EF and LINQ) they are very clearly switching their focus to the use of data transfer objects (DTOs) or Entity Objects (also basically DTOs).
That's still not great news, because ultimately I think we want responsibility-driven business objects, but certainly it is a step away from the DataSet. And, frankly, this DTO/entity model is the one that's pretty popular in the Java space too - which makes sense since most Java apps aren't interactive in the sense of a Windows app, and that model works pretty well when you don't want interactivity.
But for Windows and WPF apps, in particular, it is better to have objects with richer behaviors. And personally I think it makes web development somewhat simpler too.
Copyright (c) Marimer LLC