Returning typed DataRow from WebMethod

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?

Hi BeanDog,

This is my first post to the managed MSDN groups, but it seems like you're
experiencing similar issues to this KB.
http://support.microsoft.com/default...b;en-us;815251

Maybe this will help point you in the right direction.



--
JASON

"BeanDog" <BeanDog (AT) discussions (DOT) microsoft.com> wrote

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?

"BeanDog" <BeanDog (AT) discussions (DOT) microsoft.com> wrote

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

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.

"Jim Rand" <jimrand (AT) ix (DOT) netcom.com> wrote

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

Hello! Good Site! Thanks you! nlyaicluoxl