Re: Returning typed DataRow from WebMethod   

"BeanDog"  wrote in message 
news:4B3F68DF-0B67-4540-9230-A61AE42FBD07@microsoft.com...
> The title pretty much says it.  I'm using the tutorial on MSDN for 
> creating a
> 3-tiered distributed application
> (http://msdn2.microsoft.com/en-us/library/aa581776.aspx), a great tutorial 
> by
> the way.
>
> So I've created a typed dataset from my database (a table called 
> Function),
> and written the following function:
>
> [WebMethod]
>    public CodeSense.FunctionRow HelloWorld() {
>        CodeSenseTableAdapters.FunctionTableAdapter t = new
> CodeSenseTableAdapters.FunctionTableAdapter();
>        CodeSense.FunctionDataTable dt = t.GetData();
>
>        return dt[0];
>    }
>
> This compiles fine, but the WSDL page is a runtime error saying my
> FunctionRow can't be serialized.
>
> I'm doing investigative work to see how I would put together a distributed
> 3-tiered web application designed for very heavy load (several hundred web
> hits per second).  Basically, the conclusion I came to was that I should 
> set
> up a SQL server of some sort as the data backend, then have an ASP.NET
> business layer doing all the business logic, then have the business layer
> expose itself to the presentation layer through either SOAP services or 
> .NET
> remoting.  The presentation layer, business layer, and database layer 
> would
> each be separately load-balanced across several production servers.
>
> These strongly-typed TableAdapters and related classes were a huge bonus 
> for
> me, since that means we won't have to create and keep up business objects 
> in
> C# that simply mirror our database schema.  And .NET's great support for 
> SOAP
> serialization would make passing these to our non-.NET presentation tier a
> trivial matter.
>
> Unfortunately, it looks like this fantastic feature 
> (automatically-generated
> strongly-typed DataRows) is going to be basically unusable since I can't 
> pass
> these objects from my business tier to my presentation tier.  That is, I
> can't return them through either .NET remoting or .NET WebServices.
>
> What's the preferred method for passing strongly-typed DataRows from a
> business-logic tier to a presentation tier running on a physically 
> separate
> server?

Sorry for the late reply. I only just started monitoring this newsgroup. For 
anyone still listening, here's my response:

1) You cannot serialize any kind of DataRow because the DataRow class does 
not have a public default constructor. You can, however, return a DataTable 
with a single row in it, or even a DataSet.
2) As soon as you start to talk about passing .NET-specific types between 
layers, you are no longer talking about using Web Services. The Web Services 
platform is meant to be platform-neutral. Any platform dependencies that 
sneak through are the result of magic or bugs, and should not be relied 
upon. If you need to communicate between tiers of the same application, then 
you should use .NET Remoting instead. It can be configured to use either 
SOAP or binary encoding.


--------------------------------------------------------------------------------
John Saunders | MVP – Windows Server System – Connected System Developer

date: Thu, 30 Aug 2007 16:24:53 -0400   author:   John Saunders [MVP] john.saunders at trizetto.com

Re: Returning typed DataRow from WebMethod   

Platform-neutral is good.  However, if you control both ends of the pipe, 
Web Services are absolutely incredible for passing datasets across the 
Internet via HTTPS beween the server and "smart-client" applications.  So 
what if a dataset is not platform-neutral.

The performance absolutely blew me away.  A ten row update, which requires a 
round trip to return auto-increment keys and timestamps, took the time of a 
finger snap!   A retrieval for a complex multi-table dataset returning over 
10,000 rows took less than 4 seconds.  (Granted, this is over TimeWarner 
Road Runner cable).

Plus, it is incredibly simple to do.



> 2) As soon as you start to talk about passing .NET-specific types between 
> layers, you are no longer talking about using Web Services. The Web 
> Services platform is meant to be platform-neutral. Any platform 
> dependencies that sneak through are the result of magic or bugs, and 
> should not be relied upon.

date: Thu, 30 Aug 2007 16:48:07 -0400   author:   Jim Rand

Re: Returning typed DataRow from WebMethod   

"Jim Rand"  wrote in message 
news:OhfITc06HHA.5980@TK2MSFTNGP04.phx.gbl...
> Platform-neutral is good.  However, if you control both ends of the pipe, 
> Web Services are absolutely incredible for passing datasets across the 
> Internet via HTTPS beween the server and "smart-client" applications.  So 
> what if a dataset is not platform-neutral.
>
> The performance absolutely blew me away.  A ten row update, which requires 
> a round trip to return auto-increment keys and timestamps, took the time 
> of a finger snap!   A retrieval for a complex multi-table dataset 
> returning over 10,000 rows took less than 4 seconds.  (Granted, this is 
> over TimeWarner Road Runner cable).
>
> Plus, it is incredibly simple to do.

Yes. See below. It will work very well, until it doesn't.  When you wonder 
_why_ it doesn't, the answer will be something like "because Web Services is 
meant to be a platform-neutral technology, and you just tried to use it for 
something platform-specific that the magic didn't hide".

>> 2) As soon as you start to talk about passing .NET-specific types between 
>> layers, you are no longer talking about using Web Services. The Web 
>> Services platform is meant to be platform-neutral. Any platform 
>> dependencies that sneak through are the result of magic or bugs, and 
>> should not be relied upon.

--------------------------------------------------------------------------------
John Saunders | MVP - Windows Server System - Connected System Developer

date: Fri, 31 Aug 2007 17:21:04 -0400   author:   John Saunders [MVP] john.saunders at trizetto.com