![]() | |
![]() |
| | Thread Tools | Search this Thread | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
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? |
#3
| |||
| |||
|
|
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? |
#4
| |||
| |||
|
|
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. |
#5
| |||
| |||
|
|
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. |
#6
| |||
| |||
|
![]() |
| Thread Tools | Search this Thread |
| Display Modes | |
| |