ADO.NET Data Services - Building a WPF Client

DotNetShoutout — Sat, 17 Jan 2009 07:01:01 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

re: ADO.NET Data Services - Building a WPF Client

Donald — Mon, 19 Jan 2009 10:05:22 GMT

So can I work offline, save to a file like a dataset diffgram... then later reload the dataset diffgram and save changes back to the server?

re: ADO.NET Data Services - Building a WPF Client

Emmanuel Nuyttens — Mon, 19 Jan 2009 10:53:13 GMT

Hi Beth,

Nice example of using ADO.NET DataServices, but I have some doubts ... namely there's a lack of abstraction between the layers !

Let me explain:

In your code, you do the next:

// Declaration

Private DataServiceClient As New NorthwindEntities(New Uri("http://localhost:1234/Northwind.svc"))

// Direct use of the DataService, lack of abstraction !

Me.CategoryLookup = (From c In Me.DataServiceClient.Categories _

Order By c.CategoryName).ToList()

So the WinClient here is calling directly the DataAccesslayer.

In former demos , you abstracted the DataLayer from the client by means of a wcf service. This service routed the client calls from and to the client.

So, for example, we had a method in our DataAccesslayer called GetCustomers() which did the reald db-connection and executed the linq-query to return a bunch of customers.

Then our Middle-Tier WCF service called this method (GetCustomers).

finaly, in our WPF or WinClient, we only had a proxy to the WCF service, calling the GetCustomers() method from the service and retruning as List Of Customers.

... Or did i miss something here ?

Anyway, thanx for any response,

Emmanuel Nuyttens,

.NET Architect

BERCO NV.

re: ADO.NET Data Services - Building a WPF Client

Beth Massi — Tue, 20 Jan 2009 02:20:33 GMT

Hi Emmanuel,

I wanted to make the sample as simple as possible so there is just one client project and one server project which includes the service and the database access via an entity data model. However you could of course split the entity data model into a separate project and reference it from the service.

There is abstraction though. The proxy to the service (how you call it) is generated on the client when you add the service reference. This proxy contains a client-side representation of your entity types. These types do not necessarily map directly to your database tables, however in the example I did do it this way for simplicity. Having this proxy also means that you can write LINQ queries over these types and the client framework will send the requests to the service as HTTP GETs (because it is a RESTful service) over the wire for you when you access the results of the query. You can play around with this in Fiddler.

The beauty with ADO.NET data services is that it's automatically setting up all the plumbing to query and update your data model remotely. However the entity types that are returned are not true business objects, they are just data objects (only properties no behavior). You can extend these but unfortunately you cannot type share them on the client and the server. In many cases you may need more complex business rules besides just simple validation and want to share common business types. In those cases it's better to create your own data contracts and return real business objects like I showed previously.

HTH,

-B

ADO.NET Data Services - Enforcing FK Associations and a Fix for Deleting Entities

Beth Massi - Sharing the goodness that is VB — Wed, 21 Jan 2009 06:15:04 GMT

Last post I described one way to build a smart client in WPF against ADO.NET Data Services. In this example

ADO.NET Data Services - Intercepting Queries and Adding Validation

Beth Massi - Sharing the goodness that is VB — Thu, 22 Jan 2009 07:53:12 GMT

Last few posts I've been building a WPF client against ADO.NET Data Services, if you missed them: Using

ADO.NET Data Services - Intercepting Queries and Adding Validation

VB Feeds — Thu, 22 Jan 2009 12:00:57 GMT

Last few posts I've been building a WPF client against ADO.NET Data Services, if you missed them

ADO.NET Data Services - Building an Excel Client

Beth Massi - Sharing the goodness that is VB — Fri, 23 Jan 2009 09:46:28 GMT

Last few posts I've been building a WPF client against ADO.NET Data Services, if you missed them: Using

ADO.NET Data Services - Building an Excel Client

VB Feeds — Fri, 23 Jan 2009 12:32:47 GMT

Last few posts I've been building a WPF client against ADO.NET Data Services, if you missed them

re: ADO.NET Data Services - Building a WPF Client

coolduds — Sun, 19 Apr 2009 18:58:14 GMT

Hey Beth,

thanks for the example. I've been having some problems with getting a WPF window to refresh when the underlying source data updates. It just all goes blank.

To check it out, I've created a WPF window, with a textbox in which I enter the key. Click a button, and that fills a dataset with the one record corresponding to the key.

Some other textboxes are bound to various fields in the record.

The first time, when the form is first opened, it works fine.

After that, the textboxes just go blank.

To refresh I do:

Me.DataContext=Nothing

Me.DataContext=Me.dataset.table

Any ideas on what is happening? Have I give enough info? thanks much. jen.

re: ADO.NET Data Services - Building a WPF Client

coolduds — Sun, 19 Apr 2009 21:59:01 GMT

Figured out my last question already - about refreshing the datacontext. Turns out that once the dataset is updated, need to physically move to the first record even tho there is only one record in the dataset. jen.