Re: WCF Contract Design Best Practices Question

Tech-Archive recommends: Speed Up your PC by fixing your registry

On Aug 17, 1:05 pm, "FlyFishGuy" <FlyFish...@xxxxxxxxxxxxx> wrote:
I'm fairly new to WCF. I have a project, which I already have a lot of time
already invested it, which involves much data processing and cross
application communication. WCF seemed like a great way to go, moving
forward.

I have been diligently designing thread-safe classes to meet future needs.
WCF doesn't seem to like classes without Set methods, so I find myself
butchering work I have already done to be able to pass my objects back and
forth over the wire.

Being new to all of this, I don't want to take the wrong path, with regard
to my design principles. In a situation where I want to utilize my existing
code and plan well for future development, I'm in need of a sound approach.
It just seems as my classes grow in complexity, I'm faced with the options
of stripping them down to work with WCF or creating redundant copies of the
classes, which are difficult to maintain.

Should I just forget about readonly properties and private variables and
make everything public variables? Should I create a duplicate watered down
version of every class I have to accomplish the same thing? Does it make
sense to inherit WCF amicable classes from my existing classes and extend my
readonly properties with write access? Should I be attempting to add the
<DataMember> attribute to my private variables and ressurect public access
on the client?

I just don't want to go down the wrong path and regret it later. I can see
already that I'm going to have to make compromises, I just don't want to end
up in a box.

Any thoughts, suggestions, or references to documentation would be greatly
appreciated.

In my experience, I generally create separate classes with public
properties that are used just for the web service. I tend to keep
these separate and hopefully static without being affected by my
underlying classes. I then have conversion routines that will convert
one from the other. But, it sounds like that you have a lot of
classes, and this hasn't always been my case. But, I prefer having
the separate web service objects so I can fine tune them for their
purpose without having to push this requirement down to my other
business objects.

I tend to make them separate in hopefully also keeping the web service
mostly static and not changing much since this may require that the
client also be kept up to date. Not a big problem for internal
products, but could be a bigger issue if distributed to external
customers. You may want to update logic and classes on the server
without it affecting the clients.

Also, some .NET objects cannot be serialized directly across the wire,
such as Collections. So, the web objects may be an array of object,
e.g. foo[] GetFoos(), while the internal business objects may be
collection or other non-web service compliant object.

If you do have a lot of classes, possibly you could use a generic
conversion method between web service objects and business objects
using reflection without having to write a custom convert function for
each one. Could be a little slower if lots of objects, so something
to consider.

I have also used general objects for passing values that I expect to
change. For example, may create a Property object that has a name and
value, and then add array of the Property objects to another class.
This allow me to pass general property values without having to create
a specific new property for each item. Allows some extensibility
without having to change the web service contract.

Ron

.

Relevant Pages

  • Re: Issues hosting WCF web service object in IIS
    ... I'm trying to get my head around the real advantages of using WCF ... The bottom line is non WCF Web service solutions are being leveraged out/depreciated in future versions of VS and the .Net Framework in favor of WCF. ... Now my problem is getting this thing hosted in IIS. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: upgrade .asmx to .svc
    ... We'll also need to take care one more thing: if I expose a WCF endpoint as ... and servicing old clients. ... Keep the web service up until everyone is off it. ...
    (microsoft.public.dotnet.framework.webservices)
  • Points from Indigo Roadshot
    ... WFC is an amalgam of material that has previously appeared in .NET, MSMQ, COM, WSE (Web Service Extensions) 2.0. ... The principle of WFC is acknowledgement that programs are becoming interface and message based, and that much of that messaging that used other protocols and be done just using http. ... Microsoft appears to be trying to clean house and consolidate some of the confusion about which of the many options to use for application development by focusing on WCF as a layer and http as a protocol for messaging and interface. ... In the code demonstration, the developer, using VS.NET05, was able to create a p2p (not just chat clients attaching to a central server, but a p2p mesh where clients could participate directly) chat application in under 5 minutes. ...
    (microsoft.public.dotnet.general)
  • create a network credential
    ... I have got a web appl in ASP.NET 2.0 which in turn calls a web service ... The request failed with HTTP status 407: ... The web application and the web service run under a common application pool ... Both the web appl and the web service are set as separate virtual ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • Re: Remoting oder WCF oder WSDL oder Socken oder oder wer?
    ... als Web Service implementieren. ... Die WCF ist im Prinzip eine Art Wrapper ... Dein Aufgabenbereich liegt aber eher im Bereich SOAP/WSDL. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)