Programming with .NET - General

Re: Re: Silverlight 2.0 missing features

bropa09 — Thu, 12 Jun 2008 13:51:08 GMT

Just thought I'd add my thoughts to the post. Having parity at the core level with styling, templating, triggers, binding and resource dictionaries (merging) with WPF is essential to help with code artefact sharing between WPF and Silverlight and also porting existing WPF applications to Silverlight.

I'm trying to build a WPF application today knowing that I ideally want to also support a Silverlight version as well. I'm trying to build it so that it will be compatible between the two but I am already using core features/syntax that I know are only partially supported (or not at all) in Silverlight. The reason why I am looking to build both is that in order to support advanced simulation plug-ins in 3D you would need to install the full desktop app (and use WPF), but Silverlight could be used as a low deployment footprint with basic 2D simulation support. The simulator visualizers are plug-ins so the basic app remains the same, but the deployment cost is commensurate with the need for more advanced simulation support. It's a choice, but one that would work if a lot of the core WPF capabilities had parity with Silverlight.

Re: Re: Silverlight 2.0 missing features

Kevmeister — Wed, 28 May 2008 02:41:14 GMT

justncase80:
It seems like the simple approach is to use the DataSet (or whatever) on the server side then use a DTO for your webservice and just bind against that directly. Pretty darn simple to me.

Just because you express the idea in one sentence doesn't make the concept itself simple. Your average .NET programmer is not going to write that DTO that you talk about off the top of their head using IL Emit methods, are they?

And I don't think you can argue that binding directly to the DataSet/DataTable would be even simpler, because there is no DTO involved. Not to mention more efficient and hence more performant.

I think we're going to have to agree to disagree on this.

Edit: Oh, and therefore we'll just have to use your suggested technique at the moment, because aside from the web-service generating these dynamic types, there's not really much else one can do - irrespective of whether your DTO consumes XML, DataTable, DataSet, whatever. DataGrid needs a first-class type to DataBind correctly. But that doesn't mean Microsoft can't make life easier for developers ...

Re: Re: Silverlight 2.0 missing features

justncase80 — Wed, 28 May 2008 02:33:43 GMT

It seems like the simple approach is to use the DataSet (or whatever) on the server side then use a DTO for your webservice and just bind against that directly. Pretty darn simple to me.

Re: Silverlight 2.0 missing features

Kevmeister — Wed, 28 May 2008 02:29:48 GMT

justncase80:
a lot of this seems like a limitation in SOAP in general more than Silverlight or a lack of datasets. It's intended to be a strongly defined public API. It really seems like the desire to use Silverlight for generalized reporting is really on the outside of it's sweetspot.

I don't think the focus on "reporting" helps issues any. A web service API based on a DataSet object is as strongly typed as a webservice taking polymorphic objects - which is what must be happening if you have a web service with only 3 functions covering numerous entities. So I don't think we can blame SOAP here.

It's simply a matter of connectability: as I've said before anyone can write a DataSet/DataTable and have that pass back-and-forth between their web-service. The more serious matter is that the serious UI controls such as DataGrid require me to repackage my data in a format fit for its consumption.

DataBinding is slow enough as it is by virtue of using reflection, and now we have numerous examples whereby people are transmitting their data in one format and then repackaging it into a dynamically-constructed type just so the DataGrid can "consume" it? That's nonsense.

And it's also different from what's achievable in say ASP.NET. Even if the approach is considered "not best practice" there's surely going to be a lot of developers getting into Silverlight (from ASP.NET) asking why they have to jump through so many hoops to deliver this kind of data to a Silverlight application.

Where is the KISS principle in what we currently have?

Re: Silverlight 2.0 missing features

justncase80 — Tue, 27 May 2008 13:44:08 GMT

a lot of this seems like a limitation in SOAP in general more than Silverlight or a lack of datasets. It's intended to be a strongly defined public API. It really seems like the desire to use Silverlight for generalized reporting is really on the outside of it's sweetspot.

Re: Silverlight 2.0 missing features

Bydia3 — Tue, 27 May 2008 03:16:48 GMT

Kevmeister:

I'm a believer in code simplicity.... construct types on the fly to send them down the wire ...I consider the lack of a DataSet/DataTable and the inability to programmatically populate the DataGrid as substantial omissions. DataBinding should be considered a feature of DataGrid, not it's only method of operation, and even worse when the DataBinding capability forces you to use a very particular method of data representation in order to make it work....
..because it is incapable of working with a more generic structure. I don't care if Microsoft don't give me a DataSet or a DataTable - I can write those myself. But to then prevent me from being able to databind against that type of data structure, well then I'm pretty much just writing adapter code for no good reason.

My point in using a dataset is to NOT construct types on the fly. Just use it as an xml wrapper with methods that help to maintain insert, update and delete state... and a simple way to bind to a datagrid to view the current rows.. Just string data is good enough. Does not need to be complex, doing xml transform on the client to display a html table was good enough for our AJAX solution... cause it is simple. For the web and javascript client, we just pulled the xml(string) from a webservice and accessed it via a javascript object much like server side untyped dataset. The untyped dataset is the type, and values are strings since that's how it comes from the server. Add in schema meta data and we can loop through a columns collection if we want to know the type of the string data and then we can create dynamic forms.

I do recognize that this may not come about because seems like Silverlight wants to go the direction of "Rich" internet app. Up to this point our AJAX had been the richest I have seen due to our inhouse built xml objects for client side access.

Re: Silverlight 2.0 missing features

Kevmeister — Mon, 26 May 2008 01:41:48 GMT

I'm a believer in code simplicity. I come from a C++ background, so Reflection is not a technique that I regularly look to to solve problems. I tend to shy away from it because of its performance implications.

There's no disputing that someone can't construct types on the fly to send them down the wire so that the client (Silverlight app) can consume them easily (in particular, the DataGrid control).

But I think we are putting the cart before the horse here. The DataGrid represents a VIEW of the data. The data you send down the wire is the MODEL of the data. In my mind the MODEL usually is not heavily dictated by the view technology, and yet here is a perfect example of that.

On the other hand, if you are modelling your data on the application/web-service tier as objects, good on you. Great to see that that approach works well for you. Unfortunately, some people either cannot do that or don't want to do that for reasons such as performance.

I consider the lack of a DataSet/DataTable and the inability to programmatically populate the DataGrid as substantial omissions. DataBinding should be considered a feature of DataGrid, not it's only method of operation, and even worse when the DataBinding capability forces you to use a very particular method of data representation in order to make it work.

Now apparently LINQ-to-SQL can generate anonymous types (whatever they are called) on-the-fly in response to queries. But not everyone is using LINQ so if this is the only "convenient" way of making this happen then it's clearly working against those (like myself) who need to implement things in other ways, perhaps to support an existing code-base.

I'll throw up one word here: Flexibility. The Silverlight way of doing things at present is not currently Flexible to the extent I would like it to be.

Back to my original comment about ITypedList support, this is simply another area of inflexibility within Silverlight which forces you to either have first-class types or instantiate anonymous types in order to get a DataGrid to work, because it is incapable of working with a more generic structure. I don't care if Microsoft don't give me a DataSet or a DataTable - I can write those myself. But to then prevent me from being able to databind against that type of data structure, well then I'm pretty much just writing adapter code for no good reason.

Re: Silverlight 2.0 missing features

samcov — Sun, 25 May 2008 07:57:27 GMT

Bydia3:

2 Right, and not just flexibility and speed but to minimize the code that gets sent down to the client.

Yes, code minimization is another benefit, you make a lot of good points.

The bottom line is that while the current way the DataGrid works is elegant, but in the pursuit of elegance, we lost the simplicity of efficient design(IMO).

I'm hopeful that we should get something that allows us to set the datagrid at the cell level, and then we can do any kind of binding we want.

I doubt MS will want to bring datasets back, but cell level access will neatly solve the problem.

Sam...

P.S. We're quickly running out of days left in May, so Beta 2 will have to be delivered next week(hopefully).

Re: Silverlight 2.0 missing features

Bydia3 — Sun, 25 May 2008 01:13:09 GMT

Samcov:

1.It's all in how you generate the classes

2. The reason you want datasets(or weak typing), etc, is generally for flexibility and SPEED

3 it uses as much reflection as we use for the object based solution to display it in a DataGrid

4. I just have a mild disagreement about the reason.

1. Right, and we generate the classes quite well.

2 Right, and not just flexibility and speed but to minimize the code that gets sent down to the client. If we want to display 1000 tables in a datagrid, we would like to just dataGrid.DataSource=dataset;dataGrid.DataMember="table"; As it is now we must code each table on the client, right? Note: I am not suggesting 1000 table in one dataset, we may have a database navigator type app. where selecting a table gets just that table from the server and displays it in a grid. The data fields may not be know until runtime.

3. Let the reflection do the work, not us. If one compares the reflection of 1 dataset to 1 object based solution then yes, code may be the same, but how about 1000 tables. Creating objects for each one increases the code. This is not a DRY (Do-not Repeat Yourself) solution, because we need to repeat code for each table and field.

4. There are many other reasons, just giving some examples.

We are thankful for the JSON addition. Previously, we created an Xml packet, much like SOAP(but more flexible), that wrapped our datasets and parameters that we sent to and from our webservice. We have dropped it and now use JSON as it removes the need for many parameters on the webserve and the data sent/received is smaller in size too.

Re: Silverlight 2.0 missing features

sladapter — Sat, 24 May 2008 13:18:34 GMT

Samcov,

So we are in the same camp too. . I agree with what you said and we are also doing what you are doing. Actually we only have one Web Service call just like you what you have described. I was showing 3 just want to compare to the WCF calls justncase80 showed us. Let's hope Microsoft gets what we want.

Re: Silverlight 2.0 missing features

samcov — Sat, 24 May 2008 07:17:09 GMT

sladapter:

Bydia3,

I'm totally with you. Finally I find someone think the same way as we do.

Not so fast. That's not a good reason, because we have EXACTLY ONE Webservice that serves up ANY ORM object from the database, we don't have to change one line of code, and we can do CRUD on it all day long. It's all in how you generate the classes, setup up the acchitecture, and the transport method(we use JSON on both client and server in SilverLight, EXACTLY the way we do in AJAX).

The reason you want datasets(or weak typing), etc, is generally for flexibility and SPEED. Reporting is the perfect example, and a solution exists for SilverLight(weakly typed JSON), but it uses as much reflection as we use for the object based solution to display it in a DataGrid.

So while I'm in agreement with what you guys want, I just have a mild disagreement about the reason.

Re: Silverlight 2.0 missing features

sladapter — Sat, 24 May 2008 01:29:23 GMT

Bydia3,

I'm totally with you. Finally I find someone think the same way as we do.

Re: Silverlight 2.0 missing features

Bydia3 — Sat, 24 May 2008 00:17:01 GMT

--You can use compeltely strongly typed objects right in the webservice. How is a dataset even close to as good as this?--

--OK, Here is my case: We simply can not pre-define a object with hard coded properties. --

I agree with both these statements, it is not strong typed datasets that some of us are after. When we get a UnTyped dataset we can also within the same Untyped dataset retrieve some meta data that we can setup a dynamic forms. In this way, we can lower the amount of code we need to write and still make a generic data management system look likes it written specifically for the data in mind. So how is a dataset even close to as good as strongly typed objects? When the dataset is a UnTyped one and a 1000 webservices become 3 generic ones. Our company created an (internal use)AJAX web site, back when MSXml 3 first came out. We wrote a one method webservice that all client data passed through. It sure save alot of coding. Hoping we an do something similar with Silverlight 2

Re: Silverlight 2.0 missing features

samcov — Fri, 23 May 2008 21:48:41 GMT

We use ORM, and what SilverLight offers works for most situations, but is inferior for some applications where being closer to the metal(database) is prefered. These applications generally revolve around transforming data when SPEED is an issue.

If you have a highly used reporting site, getting data to tables as fast as possible is what is needed. Converting to Objects is an unnecessary step.

It all depends on the application, however, if you close off access to other options, that generally results in problems.

Re: Silverlight 2.0 missing features

sladapter — Fri, 23 May 2008 19:09:33 GMT

justncase80:
You can use compeltely strongly typed objects right in the webservice. How is a dataset even close to as good as this?
[WebMethod]
public MyComplexObject Get(int id)
{
return new MyComplexObject(); // do data access here
}
[WebMethod]
public void Update(MyComplexObject obj)
{
// do update here.
}

Then in code:
MyComplexObject obj = client.Get(100);
obj.SomeField = "new value";
obj.NestedComplexObject.SomeNestedProperty = 10;
client.Update(obj);

You can even use partial classes to add members to these generated proxy objects. Or what would be even better is to create actual business objects and use these proxy classes as a DTO to load that more complex business object. How on earth is this not better in every way to a dataset?

OK, Here is my case: We simply can not pre-define a object with hard coded properties.

Say we have a customer object which has a main DB table map to it. The customer could have some pre-defiend fields such as name, address, gender etc. But each Company who bought our product has different set of attributes to define their customer object and they can add attributes to the customer object and add fields to the Customer table as they like. So how can we use the Entity/Object model plus LinQ to achieve this.

Currently we use dynamcially generated SQL + DataSet + MetaData (the data to describe each object field such as mapped db field, field type, field control in UI etc) we can do everything. In our List pages we use DataGrid to display data. Each end user can chose which column to display from a list of all the possible columns for that object. User can define a filter based on each possible column as criteria. So we cannot pre-define a SQL or LinQ statement. They have to be generated dynamically.

The generic feature of DataSet is it's advantage I do not see other technology provide. I like the elegant programming style of new Entity/Object Model/LinQ and I can see their usage. But currently they still can not do what we need to do.

We have more than 1000 tables in our data base, but we only need 3 Web Service functions to cover 90% of usage in our application.

[WebMethod]

public string GetData(Filter filter)

{

//Calling our business object based on the BusinessObjectID and Filter Criteria in Filter object to get the Data back

return DataSet.GetXml(); // return DataSet XML
}

[WebMethod]

public void Update(DataSet dt, BusinessObjectID ID )

{

// calling business object to do the data set update

// business object knows how to build Update SQL based on the Meta Data for that object and Data in the DataSet

}

[WebMethod]

public void Delete(BusinessObjectID, ID)

{

// calling business object to do the delete
}