N-Tier Object datasource and Gridview

[Larry Charlton]

I seem to be having a mental block for some reason.

Some goals:
A web form with fields
A web service that processes those fields
Send the fields as a single parameter to the web service
Use an object datasource to populate the form
Object datasources get values from properties in classes

How do I structure a class so that I can marshal data in a web app (from the
screen) and in a web service (from the database) while still allowing it to
be bound to a datagridview or formview and be sent as a marshalled unit
accross the wire? (i.e. I don't want to invoke the web service to set each
property)

Or do I just have to manually create tables and not use data binding?

What's comming to mind is using a class/structure with public members and
then writing code to move it in and out of another class with properties?
Ouch.

[olrt]

Classic architectural design :

Let's say that you designed a typed DataSet : MyDataSet
You bind your Webform controls to an instance of MyDataSet (in fact
there's a middle object between controls and Data that is called
DataBind).

Your Webservice should have two methods :
FillDataSet(MyDataSet ds)
UpdateDataSet(MyDataSet ds)

Your ASP.NET application should call FillDataSet to obtain data, and
call UpdateDataSet to update data.

So the architecture is :

Web form <--Serialized DataSet--> Web service <--SQL--> Database

[Larry Charlton]

I found the following:

If I create a class that has properties in a web service and in another
class that has web methods, return the first class. My application when it
gets a reference to the webservice will also get a reference to the class (I
assume with no functionality). I can then send and retrieve this class and
getting/setting individual properties are not sent accross the wire.

Larry

[olrt]

You are talking about "serialization" of objects.
You can mark serializable properties with the metadata [Serializable].