Re: Web service, generics and complex data types

"Mike" <mike@xxxxxxxxxxx> wrote in message news:E4289F30030848D3A987EF5AF8A0372D@xxxxxxxxx
John, I really appreciate the time you've taken to answer to may
question.

This is the work around that I found.

I have all my vanilla classes in a project called Entities.
The web service reference this project (or DLL) and of course he know
what an object Customer is.
What I have in the web services are methods what will return a
serialized binary byte array.
In the client side, I will deserialize and cast back to the proper
object type (the client needs to reference Entities DLL though.

If I have to expose the web methods to third parties, I will use SOAP
serialization instead, to return raw XML.

I'm sorry, but you've made precisely the mistake I was talking about, and it's a very serious mistake.

Your client and server _cannot_ use the same DLL with web services. The fact that you have discovered a hack that seems to work does not change this fact. For instance, what about versioning? You'll have to change your client in lockstep with your server.

In fact, you have tightly bound the client and server together. They'd just as well be one thing, except that they are on different machines with a network between them.

You should be using .NET Remoting instead of web services. In fact, you seem to be re-inventing .NET Remoting as you go along. It will do all of this for you, and it will do a better job of it than you are likely to do, as they have considered scenarios encountered by many users, not just those that you have thought of already.

I benchmarked it and response times sound pretty fair to me.
What do you think about the solution?

Performance is only an issue in a single release. Your solution is unsupportable over the lifetime of your application. Among other supportability problems, you're the only person I've ever heard of who has implemented something like this. Any new developers you bring in will be unfamiliar with such a unique implementation. Around here, many would decline to work for a company that used such an implementation.

Please research .NET Remoting, or else learn how to implement Web Services using a thick wall between the client and server. This wall should only have small holes in it through which only XML may pass - not objects.
--
John Saunders [MVP]

.

Relevant Pages

  • Re: How to return a user-defined data type object from a webservice?
    ... John Saunders | MVP - Windows Server System - Connected System Developer ... It's just not how Web Services works. ... The paradigm of Web Services is all about interoperability between client ... Web Services standards. ...
    (microsoft.public.dotnet.framework.webservices)
  • Re: Best Means: Calling a Function or Application on a Remote Server
    ... applications on the database server. ... .NET remoting is another option. ... and on how you implement the server side. ... Web services for that, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Windows Authentication, Single sign on and Active Directory
    ... The server is always in the domain. ... On a client machine, if I am ... Your web services can then determine the identity of the authenticated ... Co-author of "The .NET Developer's Guide to Directory Services ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Communications between different .NET Applications
    ... large chunk of data around use .net remoting. ... bit harder to setup and get running than web services but it better ... Web services you will essentially have the clients talking to the server ... > My desire is to have client versions of my application running on a couple ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Alternative to Remoting?
    ... > server and retreive them later. ... > I thought about using web services, but they doesn't mantain the table to ... You could create a new reader, ... > In Windows Applications the solution is using .NET Remoting but I found ...
    (microsoft.public.dotnet.framework.compactframework)