The object that I described is a plug-in of a kind. There may be dozens of these objects loaded simultaneously, all having different types. Now, if I take the Refliections path, I essentially end up creating dynamically a SOAP stub for each of these objects, paying a heavy toll on resources critical to my app: increased startup time, increased memory footprint.
Instead, I want to have each loadable class implement a standard interface that is used to exchange the SOAP RPC messages. In that case the use of Reflections API is limited to instantiating the object / casting it to the mentioned interface. The object itself will be responsible for mapping the request message to its internal interface: faster, smaller footprint, less start-up processing required. Sergey -----Original Message----- From: Mike Woodring [mailto:[EMAIL PROTECTED]] Sent: Monday, September 23, 2002 14:04 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Processing SOAP RPC requests Out of curiosity, why have you discounted using reflection? If you're okay with using serialization via the [Serializable] attribute -- which is reflection driven -- why have you ruled out doing it yourself? Without knowing exactly what you're doing, it seems like the cost of reflecting against something in-proc would be outweighed by the network transit time of the soap request/response messages... -Mike http://staff.develop.com/woodring http://www.develop.com/devresources ----- Original Message ----- From: "Sergey Chemishkian" <[EMAIL PROTECTED]> > One way to avoid making extensive use of the Reflections API ... You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
