Object Data Source Binding - Forms vs Web
I've had a search through the forum for an answer to this, or a similar question, as well as MSDN, but no luck, so am creating a new post.
I have created asp.net forms in vs2005 using object data sources, and was pretty impressed how flexible they were, and you had the ability to map operations to business methods (select, insert, update, and delete), and specify sources for parameters (eg, if select was ByID, you could tell the wizard where the ID was to come from). My Business Object basically just wrapped TableAdapters from a dataset (eg, the update method bound to:publicint Update(SCIPDataSet.SeniorDataTable seniorDataTable)
{
SeniorTableAdapter seniorsTA =newSeniorTableAdapter();
return seniorsTA.Update(seniorDataTable);
}
). I thought it was pretty brilliant how it worked in the .net Web world. Very flexible and powerful.
Now, in Windows Forms, I tried exactly the same thing, using the same business object I was able to bind to in the web world. I could not use that same business object as a data source
From what I could see, the paradigm was not the same. Not in the same ball park, or even in the same State, or same planet I'd hazard to say... I could not use that business object as an object data source. From the examples I could find (very simplistic ones) it seemed to revolve around using an Object that implemented a collections interface.
I guess my question is:
Is this object data source binding paradigm disparity just how it is at the moment in Beta, and the Forms object data binding hasn't been done yet? Or is it going to be left like this in Forms with the vs2005 release?
Hi
We do have slightly different models as we have very different underlying architectures between client and web. However, what may be a little confusing is how we’ve optimized the user interaction to the form/page models of each platform. Since web pages are post response type models it was easier to map select, insert, update and delete along with parameters to controls. For smart clients this was a bit more difficult and implied specific design pattern. The asp.net ObjectDataSource control guides you down picking methods. For client, we simply just need the object you wish to bind to. For DataSet/TableAdapters simple bind to the DataSet/DataTable. For objects, even those that use TabelAdapter to fill your objects, simply choose the object you wish to display. You can then write the on-liners to fill/save your objects. I’ve posted some content related to this on our team blog @ http://blogs.msdn.com/vbteam/archive/category/4754.aspx
I’ve also written some articles on our object binding features for Code-Magazine @ http://www.code-magazine.com/Article.aspx?quickid=0409051, http://www.code-magazine.com/Article.aspx?quickid=0411071
I do appreciate your comments on the different user experience. Both the ASP.net and Smart Client teams wanted to really focus on our core user scenarios. Both teams have done some great new strides and we worked hard to incorporate each teams features into the others. There are many examples of this, and we do plan to continue to incorporate these in releases after Whidbey.
Thanks
Steve Lasker
Program Manager
Visual Studio Smart Client Data
Hmm. It is a little unfortunate I think. The flexibility and lack of code needed in the asp.net 2.0 version for binding objects is very impressive.
And web services? With asp.net you can use them like other object data sources. I believe the forms version will only bind to webservices that return datasets. This is also rather inflexible - there are actually webservices in the world that don't deal in datasets, and there may be a need for a forms application to be able to easily bind to them. In the asp.net interpretation of object data sources, this is easily achieved.
I guess my thoughts are coming from the perspective of building a prototype integrated .net solution (as we are looking at). In theory, we should be able to have the same back end/ business layer and place a thin forms front end on it or an asp.net front end. Due to the fact that the consumprion of data is totally different, it is going to mean that the forms version of a page is going to require more unnecessary custom code written to use the same back end as the web version. It is going to be simpler doing this in the web version which I find very surprising.
Or as another example, creating a forms or web based solution using non dataset, non-asmx web services. Once again, in the asp.net concept, no worries. In the forms version...
