Re: WCF Advice

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Bill,

Well, I would definitely have the data types and the contracts in one
dll. However, by contracts I mean the INTERFACES ONLY. The interface is
the representation of the contract in .NET, not the implementation. That is
separate on your service. The service and the client would share the dll
that has the interfaces and data structures that are passed between client
and service.

However, you don't HAVE to use the same DLL between the client and the
service if you don't want to. If you are publishing your metadata through
Metadata Exchange, then you can have VS.NET connect to your service and
create the proxy and all data types needed automatically. This is the
purpose of DataContract. It allows for objects that are different in the
..NET type system to be equivalent over the wire (this was primarily because
not all communication in WCF is .NET to .NET, so you can't exactly pass an
interface/structure around to a Java client, for example).


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx

"Bill McCormick" <wpmccormick@xxxxxxxxxxxxxxxx> wrote in message
news:upc6tecQJHA.1164@xxxxxxxxxxxxxxxxxxxxxxx
Nicholas Paldino [.NET/C# MVP] wrote:
Bill,

I would worry more about the design of the service. If the service
creates the object and returns it but the object doesn't need any
specific values set by the service, then this is a bad idea.

If the service doesn't require the values of the object you are
passing to it for the operation you are calling, then that's a bad idea.

Also, you might want to make sure it makes sense to mix your inputs
and outputs like that. It might not make sense from a design standpoint
to have the inputs and outputs mixed on the same object.

Take for example, if you had a method to get the name of the computer
the service is running on. If there is a string parameter that you pass
to it by reference, then that doesn't make sense, since there is no
special initialization of the string that you need to pass to the
service.

Yes, the design is what I'm focusing on at this point (sorry if I didn't
make that clear.) At the risk of appearing slow, I'd like to just follow
up with a sort of confirmation just to make sure that I understand; I
don't want to fly off in the wrong direction. :) Let me provide a little
more background:

A host application will have a number of different WCF services.
ServiceContacts will provide a pair of OperationContracts: one for sending
a collection objects (defined by a CollectionDataContract of DataContract
of class X) and another for retrieving a collection objects (again, CDC of
DC of class X).

So, the design in a nutshell: Both client and host applications will
reference a Service.dll which provides definitions for contracts. When
sending, the client app will create a collection of X, connect to the
service and call OperationContract "A" passing the collection as a
parameter. When receiving, the client app will connect and call an
OperationContract "B" that will return a collection of X.

So, am I starting off in the right direction? Am I missing anything small
or large? Would it be better to split the the Service.dll into
DataContracts.dll and ServiceContracts.dll, where the client app only uses
the DataContracts.dll and the host app uses both?

Thanks,

Bill


.

Relevant Pages

  • Re: WCF Advice
    ... I would definitely have the data types and the contracts in one dll. ... The service and the client would share the dll that has the interfaces and data structures that are passed between client and service. ... If you are publishing your metadata through Metadata Exchange, then you can have VS.NET connect to your service and create the proxy and all data types needed automatically. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: problems marshaling arbitrary sized arrays of structs
    ... dispatch interfaces. ... What happens now is that when the dll client tries to create an object ... This means that you have _not_ built or registered proxy/stub DLL after ... Check what you have in the registry under HKCR\Interface\{Your ...
    (microsoft.public.vc.atl)
  • Questions about Exporting Types from an Assembly
    ... interfaces and two coclasses. ... The COM Client was already using a COM version (compiled from an IDL, ... complains that it cannot load a DLL. ... enumeration name and an underscore. ...
    (microsoft.public.dotnet.framework.interop)
  • COM DLL registration
    ... I have created a COM DLL using ATL. ... It contains two interfaces. ... client failed with "Class not registered" error. ... then copy the DLL from CD and manually register it using ...
    (microsoft.public.vc.atl)
  • Re: Do Postconditions Include External State Changes?
    ... >>the messages generated in the contracts in the second version. ... > But wouldn't the client of A.method want to know that A's state will ... expects an entire sequence of operations. ... behavior responsibilities at the object ...
    (comp.object)