Silverlight 2 Databinding Generic

05-23-2008 2:57 PM |

Good day,

 I ma looking for a way to bind a TextBox (or other controls) in code using :

MyBinding = new System.Windows.Data.Binding("Col1");

MyTextBox.SetBinding(TextBox.TextProperty, MyBinding);

to a generic class without actually having the property Col1 but using the Indexer :

Re: Silverlight 2 Databinding Generic

05-26-2008 12:03 AM |

Hello, I don't understand your scenario very well. But this works fine for me (tb is a TextBox):

source.Add("1");

source.Add("3");

tb.SetBinding(TextBox.TextProperty, b);

Re: Silverlight 2 Databinding Generic

05-26-2008 9:40 AM |

Many thanks but...

This simple binding scenario doesn't work for me because wrtting a class for each table and putting it in a list is not an acceptable programming method for me. Too much useless code in my opinion. I am more a DataSet type of guy since the database already knows the table structure.

 So to be more understandable, I have written a DataSet class with table, column, row structure (same way as DataSet =

MyDataSet.Tables[0].Columns and MyDataSet.Tables[0].Rows[0][0]

 I bind the form using

Re: Re: Silverlight 2 Databinding Generic

05-27-2008 2:37 PM |

Thanks again for this reply.

I have tried this before but the problem with it is that when you change the row using LayoutRoot.DataContext = source[RowIndex]; the values don't update in the controls.

Concerning DataSet, I am not suprised by your comment as I read other of your threads. Many of us see the DataSet as a local DataContainer that can be used without writing much code; it is an organised collection of collections. The same as List<peoples>  List<people> but without having to write the classes; what is beautiful is that it could be self defined by using a simple SQL statement.

In this architecture, I use WCF to get (and update data), I use Linq genericly in Silverlight to convert the XML to the generic class (DataSet) for navigation and editing, and the DataSet sends changes back to the WCF. This works perfectly without having to write any classes. It is the same structure as presented in many Silverlight tutorials except for the extra work having to rewrite every Linq code section and writing endless classes for each and every form. Real world applications can have many 100 of forms; imagine all the code that can be saved. All this with only 9K bytes!

The only problem, the binding!

 Hope this gives you a different point of view.

 Cheers.

Re: Re: Re: Silverlight 2 Databinding Generic

05-28-2008 5:08 AM |

In this case, I'm afraid you have to recreate the binding:

b.Source = source[0]["1"];

But I wonder why does your service return xml? Are you creating a REST service? If so, you can use ADO.NET Data Service. Comparing to WCF, ADO.NET Data service is easier to build if you're creating a data driven service. The support is likely to be added in Silverlight Beta2. If you're creating a SOAP service, you can just use LINQ to SQL designer to generate all the classes for you, and on the client, the service proxy will also generate all the classes for you. You don't need to write a single custom class.

Regarding DataSet, I understand the benefits it brings to traditional LOB applications where no SOA is required. Sometimes you don't even need to write any code. Just drag and drop a DataGridView to the form, configure a data source to a database, and all is done. But people do have problems with this approach. Today we want to expose our business process as services. SOA has a lot of benefits such as connected environment and reusable services, but it also complicates things a lot. If the traditional approach is fine for you, you can continue using Windows Forms and ASP.NET. With UpdatePanel, ASP.NET's GridView can perform quite well.

But, 1. DataSet uses relation model rather than object model. This requires you to think from the database perspective rather than the programming perspective. 2. DataSet can't be serialized by SOAP. You can call DataSet.WriteXml to get an xml string. But then this is merely a string. 3. DataSet is difficult to interoperate. Only desktop .NET and .NET CF understands it. 4. Client applications can only make queries that your data access application exposes. To allow new ways of queries, you have to extend the data access application. 5. It's difficult to bind non-DataGrid elements such as a chart to a DataSet. It's difficult to create rich content. That's why we need 1. O/R mapping, 2. Entity Framework, 3. WCF, 4. ADO.NET Data Service, and 5. Silverlight.

 So the conclusion is: If you don't need SOA, if you don't need rich interactive content, if your business logic is simple, just go on with DataSet. But you should understand DataSet does has its limitations. In the modern world, as a client application developer, you get data from various web services. You don't care how they're stored, but once you get the data, it's yours to interact with.