Comments

# DataSet and Silverlight | Microsoft Share Point said on May 27, 2009 12:50 AM:

PingBack from http://microsoft-sharepoint.simplynetdev.com/dataset-and-silverlight/

# Jason N. Gaylord's Blog said on May 27, 2009 4:57 PM:

If you are looking to follow this series, be sure to subscribe to my RSS feed at http://feeds.jasongaylord

# ASPInsiders said on May 27, 2009 6:02 PM:

If you are looking to follow this series, be sure to subscribe to my RSS feed at http://feeds.jasongaylord.com/JasonNGaylord

# Donald said on May 28, 2009 9:11 AM:

The DataSet has many parts to it. Which parts are people asking for? That should be clarified first. In one blog some, like myself, were asking for Non-Typed Datasets and not necessarily the type that has a dataAdapter built into it.

What we want is a way to call a web service specify a workflow(some kind of selection spec) which puts the data in a dataset and returns it to the client.

Once on the client we can set the datasource to the dataset, datamember to the table and we are set to edit. We can edit the rows and have them marked with meta data as to whether they are inserted, modified and/or deleted. Cache the changes and/or submit the batch of changes back to the server for updating the database. Optionally, the dataset could be saved as a diffgram to be used for debugging, archiving, etc.

A minimum of 2 web service calls could handle an unlimited amount of datasets:

public DataSet GetData(string workflow, object[] params);

public DataSet SetData(string workflow, DataSet dataset);

Show me how to do this with Silverlight: Create an app. do do CRUD operations on a datatable, compile it, deploy it. Then add some kind of script, xml

config. that the client app can call and get a different table to do CRUD operations on WITHOUT adding code on the Silverlight app.

I've heard of I think it was DevExpress that can do Anonymous types... I think that is a step in the right direction and something that MS should do.

# Nico said on May 28, 2009 12:02 PM:

This is a bad news. DataSets are best thing that happened to developers who work with Relationnal Data (that is nearly all developers).

ADO.Net Services is the poor man’s way of working with Data, one Table at a time; While DataSets (many tables, many relations, constraints…) enable you to build complex and flexible business applications with little effort.

I follow the EF Team Blog and see how they are struggling to implement Change Tracking, Data cache, and so on just to end with an Object Model that fits difficultly to the Data that is and will be Relational for the foreseeable future. I don't understand why people are so hostile to DataSets, the .Net framework without DataSets and with only EF as means of working with Relational Data is a real bad idea.

# Todd Snyder said on May 29, 2009 10:12 PM:

This is really good news. It’s time the Microsoft world starts to move away from data centric designed. The MVVM pattern is the only real way to build Silverlight (or WPF) based applications. DataSets are only good for what they were meant to be (In memory databases) and not data transfer objects.

As far as how to handle change tracking, data caching, and so on. There are plenty of well known design patterns such as Unit Of Work and Repository that handle them.

# Donald said on May 31, 2009 8:25 AM:

Microsoft has always been about options. Implementing MVVM without datasets is not the only real way to build Silverlight and/or WPF based apps.  It is one way. MVVM can be implemented with generic non-typed objects(datasets or other) too and should be provided as an option. Don't force us to create a 1000 objects for a 1000 tables.

# Nico said on June 1, 2009 6:07 AM:

Who can do more can do less !

DataSet can do the job of DTO with no effort. Don't you have the impression of designing twice your model, whereas it should concern the same logic ?

I agree that MS power has been about options, and that we are loosing a real big opportunity to build Silverlight easily. I mean, for people used to work with DataSet, DTO and whatever MVVM pattern are quite hard to assimile. It is just a missed opportunity to get Silverlight more attractive to a lot of developpers, that feel very chilly today to move on WPF and Silverlight.

# Chris Robinson said on June 1, 2009 1:06 PM:

Just as one MAJOR clarifying point, DataSet will not be included in Silverlight, butit will always be in the .net Framework.

Thanks

Chris Robinson

Program Manager - DataSet

# Chris Robinson said on June 1, 2009 6:30 PM:

One of the points I indicated in the blog post was that we are working on bridging DataSet to other technologies. Currently we are working on a way to leverage existing DataSet WebServices by putting an Ado.Net DataServices wrapper around them. The way we are achieving this is by implementing an interface called Data Service Provider using Ado.net Data Services v1.5. We will be releasing this code to the public so that this can be one way that people can move foward to leverage existing DataSet webservices for Silverlight. I will send out more details when we release this.

Thanks

Chris Robinson

Program Manager - DataSet

# Donald said on June 1, 2009 9:13 PM:

I know the dataset will not be included in Silverlight... but sure would be nice if it was supported as an optional addin library on the client for databinding non-typed data and for persisting to diffgram xml.

# Nico said on June 3, 2009 3:16 AM:

Of course, we hope that DataSet will always be in the .Net Framework ! But, as Donald said, when we use DataSet as non-typed data container to support generic DataBinding, we would like to make it work also with SilverLight. And ADO.NET services won't help us to do the same things (I mean generic Relationnal DataBinding on non-typed data).

# Donald said on June 3, 2009 7:14 AM:

Where can we get more information about this: Ado.Net DataServices wrapper?

Will it allow us to use a single method for getting different table data as this method?:

public DataSet GetData(string workflow, object[] params);

And update different table data as this method?:

public DataSet SetData(string workflow, DataSet dataset);

If it is just to wrap the dataset and turn it into a strong typed class that we have to code for every table then I do not thing it is worth it to write the wrapper... I would rather just use the new way.

However, if it can be generic like this:

public GenericObject GetData(string workflow, object[] params);

public GenericObject SetData(string workflow, GenericObject genericObject);

then I am interested.

I want to write software not hardware.

# Nico said on June 3, 2009 12:21 PM:

Donald,

We are currently working on something that seems very close to what you describes.

I don't have any doc in english, but if you mail me (nico[at goes here]aspectize.com), I can describe what we will release in a few week (DataSet/DB mapping with powerfull client Relationnal DataBinding).

Nico

# Donald said on June 5, 2009 3:22 AM:

Was just playing with Quadrant.  I would love to simulate that kind of interface for working with databases.... however, without a generic non-typed dataset I'm not sure how it could be done.

# Sanjeev Agarwal said on June 8, 2009 6:46 AM:

Daily tech links for .net and related technologies - June 8, 2009 Web Development Using ASP.NET Routing

# Chris Robinson said on June 9, 2009 5:27 PM:

Hey Donald,

I cannot give the exact timeframe on the release of the wrapper code for DataSet. It will likely be released to codeplex within 2 to 3 months. I'm sorry I can't be more specific than that.

In terms of what it will describe. It will show how to take a Linq expression and rewrite it. Initially we were going to make this work with a webservices api where there was a webmethod for that would retrieve each DataTable and one that sets

An example would be the following

[WebMethod]

public DataTable GetCustomers()

[WebMethod]

public void SetCustomers(DataTable dt)

For your interface below

public DataSet GetData(string workflow, object[] params);

public DataSet SetData(string workflow, DataSet dataset);

Exactly what do the type of information do you take in for the string workflow, and params? This interface is confusing because its not explicit from its interface definition alone. But if I can understand this we can try to match up the sample we release with these types of requirements for the webservices that the data is retrieved from. This would make the sample more real world and useful for customers.

Thanks

Chris Robinson

Program Manager

# Donald said on June 9, 2009 9:45 PM:

Apart from the dataset as a parameter. I need to

pass a collection of key-value parameters (this could include the workflow string)

Currently, I use 2 ways to do this:

On the web client calling a web service, I create a javascript array and process as follows on the server:

[System.Web.Script.Services.ScriptMethod]

public Dictionary<string, object> GetData(object jsBus)

{

 Dictionary<string, object> ht = (Dictionary<string, object>)jsBus;

...

}

Sometimes I pass the collection both ways.

The second way with Winform as client, is to use a JsonSerializer and pass my key-value collection to the server as a string:

public DataSet GetData2(string flow, string json)

...

Before I used xml to pass the collection but with JSON my payload is much smaller.

So besides needing to pass a dataset to the service, a key-value collection or JSON object to string is needed.

# Donald said on June 9, 2009 10:25 PM:

I've had a slow start in getting into Silverlight due to my workload and seeing that Silverlight has still got a way to go before it can meet our company's business needs.  I hope it can become our primary web client business app. that we can give our customers. So I'm not yet sure about the passing of a dictionary object or serializing JSON to a string.

Concerning the meaning and types of the key-values... that is left up to the customer and workflow. That is what makes a flexible generic method work well. If the interface is explicit then it probably would not be generic. The point with passing a collection of parameters and receiving a dataset back is to be generic.

Here is a simple example to clarify some points:

[Web]

var jsBus={};

jsBus["City"]="Regina";

jsBus["Page"]=10;

jsBus["Records"]=50;

jsBus["Workflow"]="GetCustomers";

requestId=webservice.GetData(jsBus,customerCallBack);

[WinForm]

private DataSet GetData(string filter, int page, int records, string workflow)

{

var params=new Dictionary<string, object>;

params.Add("Filter", filter);

params.Add("Page", page);

params.Add("Records", records);

params.Add("Workflow", workflow);

Dataset ds=webservice.GetData(params);

return ds;

}

I hardcode some values just to show you that Most simple types can be used: string, int, long, etc.

Any number of parameters can be set.

The workflow on the back end is wired up according to the "Workflow" parameter and it will know what parameters it needs and how to convert the types: string, int, etc.

With this kind of generic coding my webservice interface and much of my client and server code need not change. All I need to do is create new parameter lists and a workflow on the backend to process them.

# Donald said on June 9, 2009 10:51 PM:

If I had a method:

public DataTable GetCustomers();

and I needed to get orders, I would need to create a method:

public DataTable GetOrders();

recompile the webserivice, publish... have to update the client proxy... etc.  Lots of work.

However, with the generic approach I described. All I have to do is create a workflow script(using a tool I have) publish to the web service workflow store (Can be as simple as saving a file).

The for the client, create a method, add some params including the workflow name as a string and I'm done. I do not have to focus so much attention on the plumbing.

Microsoft, has coming along way in helping to take care of the plumbing. But lately, I have heard of 3 companies that may have to go back to doing some of their own stuff due to missing parts.

# Donald said on June 10, 2009 3:33 AM:

Sorry, did not mean to go on and on about the genericness that I wish we could have...

I just hope that no matter what the method way... DataTable is non-typed. So we can access collections like:

dataTable["Tablename"].Rows[0]["Fieldname"].ToString();

etc....

# commongenius said on June 10, 2009 10:36 AM:

@Donald,

Having worked with several similarly "flexible" systems in the past, it is my strong opinion that the flexibility you gain with such a system is not worth the maintenance nightmare it creates. Because there is no contract at all between the client and the server - everything is an untyped heap of data that has to be interpreted out of thin air on both sides - it is far too easy to make breaking changes without knowing it. I would never again want to work on such a system, and you shouldn't subject yourself to it. Yes, that means that you have to create a GetCustomers method and a GetOrders method. Being explicit is a good thing.

# Donald said on June 10, 2009 8:44 PM:

Thank you for your suggestion. And I can understand the problem it would create if it was done wrong.

However, my experience is the other way. Implementation and maintenance is a pain because of all the "coding" we have to do.  Since we cut our actual code by 1000s+ of lines there is less to worry about.

In any case, it is up to the customer to decide.

I have done both since 1990... and strong typed back further.

We supply 2 types of software to our customers. One type using strong typed would be ok.

The other type is for maintenance. They want to type a select statement on the client and do basic edit in a datagrid. They do not accept: Just a moment while I go code this.

# Donald said on June 14, 2009 9:00 PM:

I'm very disappointed with the RIA samples (not sure about the other data access in Silverlight), very slow.  I'm wondering if it is because of all the object bloat.  I'm sure coding a Dataset like object would be much easier and more performant.

Our asp.new ajax via server methods is almost instant. Silverlight RIA is like 10 seconds slower.

# Chris Robinson said on June 16, 2009 1:49 PM:

Thanks for all the comments on how your interfaces work Donald. I do think as a previous poster indicated that the generic interface that you use can lead to difficultly of understanding the interface. However I understand how there are times that developers want flexibility.

Thanks

Chris Robinson

Program Manager - DataSet

# Donald said on June 23, 2009 9:06 PM:

New problem.  How can I do this without a non-typed generic dataset?

Our customer wants to import an Excel spreadsheet(xml format), display the contents in a datagrid and if everything is ok, post the results back to the web to be inserted into a database.

They want to control creating the db table and structure of the excel spreadsheet.  In other words, they do not want to have to call us to do any coding.

I would like to use Silverlight to do the heavy processing as doing it in asp.net usually times-out.

# Jorge said on June 27, 2009 12:26 PM:

Hi Cris,

You must considered that many Legacy Applications into WinForms that do extensive uses of dataset untyped/typed.

I have pull of services (>850) that uses dataset untyped with UI that consume it's with databing.  

I forced to not use Silverlight  OR migrating full presentation and bussiness layer.

It's must be an paradigm option For developers Not of the imposition of infraestructure.

thanks,

Jorge

# davidlgordon@hotmail.com said on July 15, 2009 11:35 AM:

Does the Silverlight team think only in FLASH? As a Developer and STOCKHOLDER, I'm am really P.O'd!

Silverlight 3 is a major setback after all the hype at MIX 09. If it can not handle Datasets it as useful as the eye candy of spinning cows in the demo's and will soon go down the path of Linq in terms of general acceptance in the majority of the developer community.

We will not be using Silverlight 3 because of its lack of Dataset support. After years of promoting ADO.NET datasets by Microsoft, it is amazing that you would let the stockholders and developer community down by not including this STANDARD in Silverlight.  

This Light is going dim...

# Chris Robinson said on July 17, 2009 11:19 PM:

Hey Jorge,

We have been thinking alot about the exact scenario you are brought up. I am aware that companies have invested heavily in DataSet business logic. There is business logic in partial classes through dataset events and also through other Business logic adapter classes.

I have been prototyping a design to proxy a set of DataSet business classes to Astoria. I believe that this will satisfy many of the needs that developers have. As I have said before we intend to deliever this to codeplex within the next 2-3 months.

Thanks

Chris Robinson

# radyo dinle said on July 19, 2009 10:37 AM:

New problem.  How can I do this without a non-typed generic dataset?

Our customer wants to import an Excel spreadsheet(xml format), display the contents in a datagrid and if everything is ok, post the results back to the web to be inserted into a database.

They want to control creating the db table and structure of the excel spreadsheet.  In other words, they do not want to have to call us to do any coding.

I would like to use Silverlight to do the heavy processing as doing it in asp.net usually times-out

# Vitaly Laskarzhevsky said on July 22, 2009 9:57 PM:

Hi Chris,

Could you look at this:

http://silverlightdataset.codeplex.com

Thank you

Vitaly Laskarzhevsky

# Shawn said on July 27, 2009 12:11 PM:

Consider in an example like creating a fully functional front end for SharePoint or CRM -- two systems that have highly flexible metadata and allow the end users to configure and customize at great lengths.

Take the scenario of a creating a Silverlight front end for a custom list in SharePoint.  Since the definition of a custom list in SharePoint is completely up to the end user it can contain any number of fields.  Since each field has sufficient metadata associated it should be possible to create a rich interface for working with the data.  

I am curious as to what are your current thoughts on allowing the developer to expose something like this to a front end platform like Silverlight.

# John said on July 28, 2009 6:49 PM:

Ridiculous... I've been supporting C#/.NET for years now since 1.0, and recently stepped into a job where my primary first task (unbeknownst to me during interview) would be coding a drill-down dashboard in Flex/Java/BlazeDS/Spring/Hibernate/Tomcat, which is a bit ridiculous given the number of toolsets needed to bring in data into a simple reporting application that will do no persistence.

I haven't done much research into Silverlight until recently because I mostly did C#/Winforms development in the past, but I assumed that it would be a less heinous stack of tools to develop with and train the business on.

No such luck as I've found out according to this post, the constraints look the same as Flex, and not even just that, while trying to get Visual Web Dev Express 2008 sp1 to do a Silverlight test, the IDE fails on XAML creation (Microsoft.VisualStudio.Xaml.dll error, reinstalling did not help).  This Silverlight development venture for me has been a trainwreck disaster.  I thought the nice thing would be that *IF* I could get the Silverlight install working and running in VS then I wouldn't have to go through XML/SOAP or some patchy binary format like AMF to get simple data from an Oracle server like I would with Flex.  Now I'm seeing here that's not the case, it's just as bad.  

It's no wonder to me why DevExpress and other vendors haven't come out with a Pivot Table control for Silverlight yet.  It wouldn't make any bit of sense with the performance hits from ORM overkill, especially in the kind of applications I find myself often tasked with where it makes absolutely no sense at all to have that extra layer, and just makes it more difficult to perform reporting tasks because usually data pulled in from a large data repository is queried and summarized using SQL expressions and statements (e.g. GROUP BY, WHERE, etc).  

I've never worked at a company that didn't have some large data repository of transactional data with millions maybe even billions of records in a single table with 80 fields or more.  Usually what an IT group or reporting group may want to do is create an end user tool that allows a user/manager to query databases and perform some limits analytics on transactions, without having the security concerns of having them hit a production database and maybe even write to it if they don't know what they're doing, and it effectively gets rid of ad hoc reporting tasks and apps to perform redundant functions.  A customer may want to be able to dig into a very small fraction of that data to do an analysis on a few transactions without pulling in all 80 columns and 1 billion rows, but in order to do that they need a dynamic solution which I'm sorry to say ORM is *NOT*.  What's sad is that I could have done all of this and have before pretty painlessly in a C#/Winforms/ADO.NET app with DevExpress's DataGrid and PivotTable that gives the user a selectable list of fields to bring in, and allows them to pull in data based on a set of predefined filters and selectable time ranges.  Using Silverlight's methods, this would be a huge undertaking.

This is very disappointing, I've already uninstalled VWDX 2008 sp1 on my machine at the office.  Please stop selling the world that this stuff is the "latest and greatest" when it's clearly not and it limits the developers.  It's created a culture where managers now want an RIA for everything but clearly that's not the solution for all problems.  You guys were doing fine around 2005 in the 2.0 era, but since then MS has been losing touch with its customer base I feel and you're imposing unreasonable constraints on developers.  I'm not knocking the ORM approach when it makes sense: i.e. you have total control over your data in your environment to create your own tables, you have an application that needs to persist records back to a database, and you have an application that doesn't need to support large scale production data.  However, clearly ORM doesn't solve every imaginable problem space, and there should always be access to the original ADO.NET methods in any .NET technology.  It's sad that projects exist like the one linked above for patchworking in the enabling of ADO.NET technology into Silverlight, it defeats the entire point of having a robust .NET framework.  It just shows that the approach you guys are taking is not in the best interests of all developers, and it's one of those things that worries me about the future of .NET-based technologies since developers will always move to adopt the technologies that will tackle the lion's share of their problems.

Oh well, there's always ASP.NET+Ajax with its flakey browser support I guess...

# Vitaly Laskarzhevsky said on August 21, 2009 11:07 AM:

Hi guys,

Silverlight DataSet (http://silverlightdataset.codeplex.com) supports binding to DataGrid with AutoGenerateColumns="False" now

Vitaly

# Vince said on October 5, 2009 2:13 PM:

You can also use the SilverlightDS components from http://www.silverlightds.com

They have wrapped up alot of code.

# G33k said on October 8, 2009 2:03 PM:

Let us manage our data, our way!!! If Siverlight means living without Dataset, DataTables, And Dataviews I'll just buiild in Flash and call web services or LoadURL an XML/Mime-Typed aspx page that returns the data it calls from a stored proc.

# Jim said on November 1, 2009 5:25 AM:

After spending the last week or so looking into silverlight I am very disappointed.  I started working on a project a couple of months ago that required mapping (Google Maps) and either silverlight or flex.  Silverlight didn't seem to have any ability to use google maps directly so went to flex.  Got the application up and running with little problems even though I had never used flex or flash in the past.  Used a Aspx website that accepted and returned xml via async http requests and used SQL Server as the database.    All database activity is done via stored procs for easier debugging and development.  We can change stored procs very easily and test without an application.  

Flex's UI support and dev environment wasn't the best but at least I wasn't forced into a specific model that required me to create 10s or 100s of classes just to process my data.   Main thing here was that Flex supports binding against xml docs, nodes, attributes and elements directly.  

After completing that app I thought why not do something similiar with Silverlight to learn it.  Silverlight has to support XML directly or at least linqtoXML would work.  I can't believe that I was so wrong with that thinking.  I haven't found anything that is close to being as easy as flex was.

What is MS thinking about with the lack of direct ADO.net support or at least XML support?  Silverlight will not become a business app player in the future unless someone wakes up and says "we need to support the developers out there that are using what we (MS) told them was the future."  

Just my two sense worth.

Leave a Comment

Name (required) 

Your URL (optional)

Comments (required) 

  

Enter Code Here: Required

Remember Me?