Programming .NET Components, 2nd Edition

.NET and Location Transparency

As explained in Chapter 1, a core principle of component-oriented programming is location transparency . Location transparency means that the same client-side code can interact both with local objects and with remote objects, and ideally, the same component can be used either locally or remotely (see Figure 10-3). Put differently, if a component works locally, it should work remotely, and if a client can use a component locally, it should be able to use the component remotely. There should be nothing in the client code pertaining to location. DCOM supported location transparency—as long as the Registry contained the right settings, location transparency was a reality in DCOM. Thus, after dozens of pages analyzing .NET remoting, it’s time to ask: does .NET support location transparency, and if so, to what degree?

This section examines location transparency with regard to marshal-by-reference objects only. Both DCOM and .NET allow marshal-by-value objects (although not with the same ease), but marshal-by-value objects clearly don’t comply with location transparency in DCOM or in .NET. I also don’t think that the location transparency principle on the component side is relevant to singleton or single-call objects. These server-activated components are different by design: a single-call object must manage its state, and a singleton object is bound to a particular single resource. However, the client of a server-activated object can still benefit from location ...