Re: remoting options
- From: "richlm" <richlm@xxxxxxxxxxxxx>
- Date: Tue, 7 Jun 2005 22:54:49 +0200
A key factor would be to use dynamic/loose binding to your "business" layer.
Avoid adding a reference to the "business" dll to your GUI project.
Instead implement some sort of factory pattern that supplies the UI code
with a PROXY to your "business" dll (e.g. GetServerObject(type,location)).
Both the proxy and the actual implementation implement a common interface
known to both client + server.
In the first instance the proxy can be a simple wrapper to the class in the
local assembly (or maybe even the class itself).
Later you can change the factory to supply a web-service proxy, a COM+
proxy, an Indigo proxy, or whatever.
Do this and you're well on the way to a service oriented architecture.
No-one says the services have to run on different boxes to start with.
Of course this proxy approach is exactly what web-services, remoting or COM+
do for you under the covers - but you have to CHOOSE one of them.
By implementing your own proxy factory your application code is more
isolated from the underlying client-server protocol.
We can look forward to Indigo - the communications architecture in
Longhorn - which will address the problem in a more elegant way.
.
- Follow-Ups:
- Re: remoting options
- From: param
- Re: remoting options
- References:
- remoting options
- From: param
- RE: remoting options
- From: [MSFT]
- Re: remoting options
- From: param
- remoting options
- Prev by Date: Re: Java programmer lured back by .Net (Questions)
- Next by Date: Recomended way of implementing business layer
- Previous by thread: Re: remoting options
- Next by thread: Re: remoting options
- Index(es):
Relevant Pages
|
Loading