Sharing Data Structures between Client and Server

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

BillAtWork - 06 Feb 2008 15:14 GMT

Hi,
I'm wondering what the best practices are in this area.

I have two projects: a windows forms app (client) and an ASP.NET web app
(server). The client communicates with the server via webservice calls.

There are a number of data structures (classes, enums, structs, etc.) that
are used by both applications, mostly to exchange data via the webservices.

Currently, the structures are declared in the web project. I have a
reference to the webservices in the client and can therefore code the
following:

Web App
======
public struct MyStruct(string data)
{
...
}

Client
====
MyObject obj = new localhost.MyStruct("hello");

At runtime, I change the webservice URL programatically to point to the
"live" webservice instead of my development webservice. The structures work
just fine but I'm concerned this is not best practice. Can it lead to any
problems?

I could manage the common structures in a third project and add references
from the client and server projects but that leads to other issues (code
management, exposing all structs to client when not necessary, etc).

Any help appreciated :)
Thanks!

Reply to this Message

John Saunders [MVP] - 06 Feb 2008 16:40 GMT

> Hi,
> I'm wondering what the best practices are in this area.
[quoted text clipped - 30 lines]
> from the client and server projects but that leads to other issues (code
> management, exposing all structs to client when not necessary, etc).

Basically, the types on the client and those on the server are meant to be
distinct. The client (proxy) types are only meant as conveniences so that
the client doesn't have to manipulate XML. These classes and other types are
otherwise unrelated to the types exposed by the server.

Signature

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

Reply to this Message

BillAtWork - 06 Feb 2008 16:59 GMT

Thanks for your reply. I can see that it's a convenience to refer to types
this way. However, the classes are conceptually identical even though they
are manipulated independently by both the server and the client and are used
to pass structured messages between the two. What is considered best practice
in this case? I'm sure this is a common requirement but I've not seen a
definitive solution.

Thanks!

> > Hi,
> > I'm wondering what the best practices are in this area.
[quoted text clipped - 35 lines]
> the client doesn't have to manipulate XML. These classes and other types are
> otherwise unrelated to the types exposed by the server.

Reply to this Message

John Saunders [MVP] - 07 Feb 2008 02:00 GMT

> Thanks for your reply. I can see that it's a convenience to refer to types
> this way. However, the classes are conceptually identical even though they
[quoted text clipped - 4 lines]
> in this case? I'm sure this is a common requirement but I've not seen a
> definitive solution.

This is a common request, and the best practice is to realize that the two
classes are not, in fact, equivalent.

This becomes much more clear when you realize that the client and server may
not even be using the same platform. Maybe the client is Java and the server
is .NET. In this case, you would not expect them to share the same class!

Signature

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

Reply to this Message

Steven Cheng[MSFT] - 07 Feb 2008 02:48 GMT

Thanks for John's input.

Hi Bill,

If you do need to use shared classes between webservice client and server,
I think you can manually change the auto-generated webservice proxy in
client proxy, modify the return type or parameter types(to match the types
in your class library project). Also, to prevent the modification be reset
when you update proxy, you can add these customized methods(of the proxy
class) in a partial class file which will not be reset by IDE. Here is a
former thread in which I also mentioned this:

http://www.developersdex.com/csharp/message.asp?p=1111&r=5859215

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
From: "John Saunders [MVP]" <john.saunders at trizetto.com>
References: <4A72BA27-F698-4226-8D24-15435D3BD423@microsoft.com>
<ea#sm7NaIHA.4160@TK2MSFTNGP03.phx.gbl>
<C5CFC833-8936-4374-A7EC-169850B91A81@microsoft.com>
Subject: Re: Sharing Data Structures between Client and Server
Date: Wed, 6 Feb 2008 21:00:25 -0500

This is a common request, and the best practice is to realize that the two
classes are not, in fact, equivalent.

This becomes much more clear when you realize that the client and server
may
not even be using the same platform. Maybe the client is Java and the
server
is .NET. In this case, you would not expect them to share the same class!

Signature

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

Reply to this Message

Spam Catcher - 06 Feb 2008 17:00 GMT

> At runtime, I change the webservice URL programatically to point to
> the "live" webservice instead of my development webservice. The
> structures work just fine but I'm concerned this is not best practice.
> Can it lead to any problems?

Web services should be loosely coupled - so what you're doing is fine.

If you need to enforce object types between client/server, you should use
remoting or WCF.

Signature

spamhoneypot@rogers.com (Do not e-mail)

Reply to this Message

Sharing Data Structures between Client and Server

Free Magazines