Vista - Migrating to WCF - Using typed DataTables?

Hello,

We've just come off creating a medium to large size client server
application

over the past 3 years using .NET 1.1 c# w/ Sql Server 2000 as the
backend. We're

about to create a similar client server project. We decided to use
strongly typed

datasets and datatables and we loved it. The ability to use
DataRelations,

Expression columns, DataViews with Filters and sorting has been very
cool! We

basically had our strongly typed datatables all derive from a
BaseDataTable that

handles the connection to the database using System.Data.SqlClient
classes.

Anyway, my question is, if we decide to move our entire model to WCF,
does that

mean we'd have to ditch using strongly typed datatables and move to
simple

data types or maybe some simple classes such as (excuse the sloppy
code):

class Person
{
public int PersonID;
public string FirstName;
public string LastName;
}

It seems we could keep the strongly typed tables and serialize them,
but i'm also curious what the recommended design approach is.

Thanks!
Dave

You will probably need to ditch them because DataTables are not serializable
(if I am not mistaking).

I face the same dilema and decided to use WCF only for heavy business logic
(create order, update customer, etc) and read database directly from the
client if I need to get orders, for example.

I have seen Guidance toolkit for WCF. The way they propose returning data to
the client seems an overkill..

-Stan


"Dave" <chakachimp@yahoo.com> wrote in message
news:1177463990.899271.253550@t39g2000prd.googlegroups.com...
> Hello,
>
> We've just come off creating a medium to large size client server
> application
>
> over the past 3 years using .NET 1.1 c# w/ Sql Server 2000 as the
> backend. We're
>
> about to create a similar client server project. We decided to use
> strongly typed
>
> datasets and datatables and we loved it. The ability to use
> DataRelations,
>
> Expression columns, DataViews with Filters and sorting has been very
> cool! We
>
> basically had our strongly typed datatables all derive from a
> BaseDataTable that
>
> handles the connection to the database using System.Data.SqlClient
> classes.
>
> Anyway, my question is, if we decide to move our entire model to WCF,
> does that
>
> mean we'd have to ditch using strongly typed datatables and move to
> simple
>
> data types or maybe some simple classes such as (excuse the sloppy
> code):
>
> class Person
> {
> public int PersonID;
> public string FirstName;
> public string LastName;
> }
>
> It seems we could keep the strongly typed tables and serialize them,
> but i'm also curious what the recommended design approach is.
>
> Thanks!
> Dave
>

Are you for real? Now don't get me wrong - I use OO classes (not
ADO.Net) 95% of the time, but I do use DataTable et al, and have had
no problems with WCF...

The idea of the client talking directly to the database is directly at
odds with the distributed data access that smart-clients are meant to
offer. I don't recommend it.

Marc

Normally you don't have any business logic in read-only components. You call
method,
methods calls stored procedure, returns data table back to the client.

There are cases when you do have some logic in read-only components, such
as:

- return only one row or throw an exception
- security and logging

Plus obviously it isolates the client from database connection string
management.

I am not advocating to read database from aspx code-behind files, it should
go through
a component, but I am not sure how WCF fits in here.

Microsoft doesn't recommend returning DataTable from WCF methods. You need
to return the custom business entities and map/unmap fields. I just doesn't
like the overhead that comes with it.

I do need to have DataTable on the client, though..



"Marc Gravell" <marc.gravell@gmail.com> wrote in message
news:uy8JO8zhHHA.4704@TK2MSFTNGP06.phx.gbl...
> Are you for real? Now don't get me wrong - I use OO classes (not ADO.Net)
> 95% of the time, but I do use DataTable et al, and have had no problems
> with WCF...
>
> The idea of the client talking directly to the database is directly at
> odds with the distributed data access that smart-clients are meant to
> offer. I don't recommend it.
>
> Marc
>

As I read it (and tend to agree), DataTables are .Net specific structures
so they are at odds with SOA. With object databinding, keeping rows as
objects and tables as collections can be easier to work with anyway. And
Linq will make this even better. At least there are some alternatives.

--
William Stacey [C# MVP]


"StanB" <stan@community.nospam.com> wrote in message
news:erEIB20hHHA.4600@TK2MSFTNGP05.phx.gbl...
| Normally you don't have any business logic in read-only components. You
call
| method,
| methods calls stored procedure, returns data table back to the client.
|
| There are cases when you do have some logic in read-only components, such
| as:
|
| - return only one row or throw an exception
| - security and logging
|
| Plus obviously it isolates the client from database connection string
| management.
|
| I am not advocating to read database from aspx code-behind files, it
should
| go through
| a component, but I am not sure how WCF fits in here.
|
| Microsoft doesn't recommend returning DataTable from WCF methods. You need
| to return the custom business entities and map/unmap fields. I just
doesn't
| like the overhead that comes with it.
|
| I do need to have DataTable on the client, though..
|
|
|
| "Marc Gravell" <marc.gravell@gmail.com> wrote in message
| news:uy8JO8zhHHA.4704@TK2MSFTNGP06.phx.gbl...
| > Are you for real? Now don't get me wrong - I use OO classes (not
ADO.Net)
| > 95% of the time, but I do use DataTable et al, and have had no problems
| > with WCF...
| >
| > The idea of the client talking directly to the database is directly at
| > odds with the distributed data access that smart-clients are meant to
| > offer. I don't recommend it.
| >
| > Marc
| >
|
|

Oddly, I'm actually normally the anti-DataTable advocate (in favor of
proper entity objects), but I can be pragmatic. If you are using WCF
as an architecture-neutral data provider (i.e. it will work the same
on the lan or internet), and your service is only for your own .Net
consumption (not as an EDI etc endpoint), then using DataTable etc
will not be a problem at all. In this scenario, you can also (to great
effect) use a shared entity assembly rather than the metadata
representation to provide a rich client-side object model.

As for them not serializing: WCF respects IXmlSerializable, and it
will just work. I don't tend to use it much for DataTable, but I can
appreciate that it is there, and I have used it on occasion to avoid
huge time (development) costs.

Before somebody jumps on me, I also appreciate that if the purpose of
the service is to provide a common end-point from other sources
(either external callers, or different runtimes), then fine: don't use
the common assmebly; use the mex extract. But I do think people need
to be a bit more pragmatic about WCF: if you go hardcore purist, then
you will have to accept the overheads of working with dumb objects.
However, if you use WCF as a tool to do a specific job (and understand
how it works and the design impact there-of), it can be used with
regular (richer) objects.

Marc

Agreed.

Passing datasets or datatables across a web service is perfectly acceptable
if
1- you are developing both the client and the web service
2 - interoperability with other client technology is not a requirement
3 - the web service is not intended for public consumption


"Marc Gravell" <marc.gravell@gmail.com> wrote in message
news:%23RImc59hHHA.4668@TK2MSFTNGP04.phx.gbl...
> Oddly, I'm actually normally the anti-DataTable advocate (in favor of
> proper entity objects), but I can be pragmatic. If you are using WCF as an
> architecture-neutral data provider (i.e. it will work the same on the lan
> or internet), and your service is only for your own .Net consumption (not
> as an EDI etc endpoint), then using DataTable etc will not be a problem at
> all. In this scenario, you can also (to great effect) use a shared entity
> assembly rather than the metadata representation to provide a rich
> client-side object model.
>
> As for them not serializing: WCF respects IXmlSerializable, and it will
> just work. I don't tend to use it much for DataTable, but I can appreciate
> that it is there, and I have used it on occasion to avoid huge time
> (development) costs.
>
> Before somebody jumps on me, I also appreciate that if the purpose of the
> service is to provide a common end-point from other sources (either
> external callers, or different runtimes), then fine: don't use the common
> assmebly; use the mex extract. But I do think people need to be a bit more
> pragmatic about WCF: if you go hardcore purist, then you will have to
> accept the overheads of working with dumb objects. However, if you use WCF
> as a tool to do a specific job (and understand how it works and the design
> impact there-of), it can be used with regular (richer) objects.
>
> Marc
>

Darn, you just managed in 3 bullets that which took me 3 paragraphs.

;-p

I changed my method to return DataSet instead of the custom collection. The
size of the proxy class increased from 35k to 75k.

I don't even want to open it - scary..

Returning DataSet definitely saves time.

Plus we've been there already, remember returning disconnected ADO
recordsets?




"Scott Holman" <sholman@micros.com> wrote in message
news:eUaXqRAiHHA.1312@TK2MSFTNGP03.phx.gbl...
> Agreed.
>
> Passing datasets or datatables across a web service is perfectly
> acceptable if
> 1- you are developing both the client and the web service
> 2 - interoperability with other client technology is not a requirement
> 3 - the web service is not intended for public consumption
>
>
> "Marc Gravell" <marc.gravell@gmail.com> wrote in message
> news:%23RImc59hHHA.4668@TK2MSFTNGP04.phx.gbl...
>> Oddly, I'm actually normally the anti-DataTable advocate (in favor of
>> proper entity objects), but I can be pragmatic. If you are using WCF as
>> an architecture-neutral data provider (i.e. it will work the same on the
>> lan or internet), and your service is only for your own .Net consumption
>> (not as an EDI etc endpoint), then using DataTable etc will not be a
>> problem at all. In this scenario, you can also (to great effect) use a
>> shared entity assembly rather than the metadata representation to provide
>> a rich client-side object model.
>>
>> As for them not serializing: WCF respects IXmlSerializable, and it will
>> just work. I don't tend to use it much for DataTable, but I can
>> appreciate that it is there, and I have used it on occasion to avoid huge
>> time (development) costs.
>>
>> Before somebody jumps on me, I also appreciate that if the purpose of the
>> service is to provide a common end-point from other sources (either
>> external callers, or different runtimes), then fine: don't use the common
>> assmebly; use the mex extract. But I do think people need to be a bit
>> more pragmatic about WCF: if you go hardcore purist, then you will have
>> to accept the overheads of working with dumb objects. However, if you use
>> WCF as a tool to do a specific job (and understand how it works and the
>> design impact there-of), it can be used with regular (richer) objects.
>>
>> Marc
>>
>
>

Thanks for all of the great feedback guys. Someone above mentioned
using DataTables on the client w/ objects/collections as the data
contracts. I was thinking of it more the other way around actually.
That is, use DataSets, DataTables behind the WCF layor (on the server)
and use simple objects and collections on the client and as the WCF
DataContracts. We like to use databinding, so one possibility is to
simply make these object collections implement IListSource (which
should have nothing to do with WCF??). If what we're saying is
viable, then LINQ would be a much antisipated feature for SOA
applications written in .NET. Currently, we're used to using all
strongly typed datatables and datasets so this is a huge change in
thinking. Can anyone elaborate on some (rather .NET specific) design
approaches to gaining the benifits of WCF/SOA and still using the
power of DataSets in a rich client/server application?

What I seem to keep reading about SOA is that when it comes to the
distributed architecture you want to think of things as services
instead of objects. I've also read that this is the single biggest
thing seasoned OO developers have a hard time grasping. I would tend
to agree and add that this very thread is a direct result of that.
In other words, I'm one of the OO developers asking questions exactly
how to use SOA. If someone chooses to use DataSets with WCF, then
why use WCF at all? Someone above said that it allows you to get ready
for the new technology, but it seems SOA is such a paradigm shift that
changing to a model of services rather than a model of objects seems
like a much bigger shift than the WCF API alone. It would seem it
would make things more difficult (and inefficient); almost like trying
to fit a square peg in a round hole. In other words, I don't see the
gain using WCF if one decides to still use traditional non-SOA style
of programming (such as DataSets, etc...)

After doing research on this issue, I'm starting to realize that using
DataSets in WCF is a rather heated topic. Check out these other
threads mostly on this specific topic. Feel free to add more links...

http://forums.microsoft.com/MSDN/Sho...76975&SiteID=1
http://forums.microsoft.com/MSDN/Sho...26054&SiteID=1
http://forums.microsoft.com/MSDN/Sho...83867&SiteID=1
http://forums.microsoft.com/MSDN/Sho...43236&SiteID=1
http://forums.microsoft.com/MSDN/Sho...74836&SiteID=1
http://www.hanselman.com/blog/PermaL...db08bb3f5.aspx
http://groups.google.com/group/micro...15f79db0a633bc
http://msdn2.microsoft.com/en-us/lib...emotes_topic16
http://groups.google.com/group/micro...eb73a1adfb8541
"When talking about remoting and datasets, it came down to the fact
that datasets were pure evil."
http://groups.google.com/group/micro...532b5eb15ed89c

-Dave