.Net Remoting - Object Referencing Issues

D

dotnetman

Newcomer
Joined
Jan 4, 2005
Messages
19
Friends,
We have been trying to break up our assemblies to move our app to a multi-machine architecture. Remoting seems to be the best option available compared to Web Services. I created my first project with a simple application. I made a listening server and a client and everything went fine. It did print Hello World on my client. However, what is troubling me is that in all the resources I have gone through, they explicitly mention that we add a reference to the target object (dll) at the client side (server side I can understand). Doesn't this falsify the very objective of remoting? If I were to access my DAL/ Business Objects remotely, will I have to add all the references on the client side then?

Do let me know coz this is killing me :(

DNM
 
Well, the client side needs to know how the remote object is structured, in terms of class members and function calls. This is why you reference the DLL the remoting object is in.

The .NET Framework handles all of the low-level stuff for you. Essentially what it does is serializes an instance of the remoting object into a stream of raw bytes and then sends them out over TCP or HTTP. The receiving end then deserializes them back into an instance of the remoting object. Obviously, in order for the client side to serialize the instance, it needs to have a reference to the object so it knows how to "package" the transmission.
 
Well I finally managed to get the answer. Most of the articles that explain remoting are BS. Why would anybody want to add all the references on the client side when the very goal we are trying to accomplish is to access our objects remotely. As long as it is Hello world and all you got is 1 dll, it is alright! But my business and data logic spans over 400 classes, not to mention our own framework classes (>500). It would be as good as moving the entire application to the client. Top it with the overhead of remoting! :D

Well, what we can do is implement an interface. All your methods that you would want to expose, add them to this interface. Make a dll out of it. Add a reference to this interface at both the ends. All your business logic definitions should go into this interface. Have your business server implement this interface. Now, the client knows what kind of an object it is accessing. That should do the job. :)
 
You don't have to put all of that in the DLL that is being referenced by the remoting client. The only thing that needs to be in the client side DLL is the remoting object. If you lay out your classes properly you can have the business logic completely separate from the objects they are operating on. All you need to do is deploy the remoting object to the client. Leave everything else on the remoting server.
 
Back
Top