Understanding how WCF works

I am using a WCF service between the Client side UI (Silverlight 3.0) and the Data Layer. We are using NHibernate for Database Access. So please tell me if my below understanding is correct or not:

• UI calls WCF for a Save Method (for eg).
• The WCF has a Save method in it which actually encapsulates a Save method from the Data Access Object.
• The Data Access Object method of Save in turn encapsulates a default Save Method of NHibernate which actually saves some Business Object/s into the Database.

Also can someone tell me that how do we pass objects from WCF to the UI (Silverlight 3.0) layer and vice versa. I have read that we use DTO for that. But how does a DTO work? Do they correspond to the 'Data Contracts' in the WCF? If not then is the DTO declared on WCF (server) side and Client side cod开发者_Python百科e as well?

No, not quite....

• UI calls the client-side proxy method Save
• the WCF runtime takes that call and all parameters being passed in, and serializes them into a message (typically a XML serialized message)
• the WCF runtime sends the serialized message over some kind of a transport media (whatever it is)
• on the server side, the WCF runtime takes the incoming message
• the message is deserialized, the appropriate class and method to handle it are identified
• typically: a new instance of a service class is instantiated to handle the request

• the WCF runtime unpacks the parameters and calls that appropriate message on the service class

• same steps - basically backwards - are done for response

Important point: the only thing between the client and the server is a serialized message (which could be sent by e-mail or pigeon courier) - there's no other connection - no "remote object call" or anything like that at all

marc_s mentions the client-side proxies, which can be generated via the service references in your Silverlight project. The generated proxies are decent enough and provide an async model for running requests from the Silverlight side; those will look mostly like remoted procedure calls.

Another approach is to use the leaner (but maybe more advanced?) channel factory directly. A simple example of that can be found here. Both methods take care of most of the serialization details for you.