As my new role in the VB team, I've been tasked to look at WCF Data bindings and determine our story for Orcas and beyond from a tooling standpoint. As a part of the VB team, we are particularly interested in enabling the N-Teir RAD data story in the Orcas timeframe.
What I've been giving thought into is the right user model for our WCF Data binding story and the various approaches that users create the forms. From data I have seen, my perspective is that several people start from the actions that they want to perform. When they see an Amazon API, they want their data grouped under their operations and not a flat list of data they could use in their forms, as their mental model is that of adding functionality to their form. For example, I want this to be the "Add Item to Cart" form. Or I want to add the "Remove Item from Cart" functionality to this form.
Another key concept is the idea of data services. Where you are thinking of the data (like DataTables) first and then the operations for that data, which are very SQL-like (or CRUD-like) in nature. For example, a user wants to add an Order and OrderDetails table to his form and be able to update/delete items as required. In this case, when the user drags and drops a datatable, he wants it to automatically hook up the Form_Load and SaveButton_Click handlers by generating the appropriate code. This is so that the behavior for datasets across n-tiers is the same as it would be across 1 tier.
Therefore, there are many ways of using the Data Sources window to design a client form using a WCF Service data source, just as they are many ways to design a service (http://blogs.msdn.com/donsmith/archive/2005/09/02/460345.aspx).
How would you like to use the data sources window to design your client form? Have I missed a scenario that you consider important?