I agree that COM makes monikers hard to use. It is a pity, because I see it as a very valuable pattern to use in instances when a generic service needs to mediate objects of virtually any kind. I would love to see a .NET moniker implementation that is simple to use and just as elegant and extensible as its COM predecessor.
The moniker pattern is about separating object binding from object use. This way object binding (activation) can be delegated to generic services not knowing anything about the object they activate, while consumers of these services may use these objects without having to know how to activate them. In the COM world, this was the basis for OLE, and OLE containers were just an example of a generic service that knows about object binding, not about the object itself. The usefulness of the moniker pattern comes from having a unified and extensible way of encoding complex object binding semantics into a symbolic object reference (the moniker). This way all complexity and mechanics of binding to a particular instance can be separated from actual use of the object, and the object reference (moniker) can be passed around to anyone that need to use that particular object. The object consumer would only have to know how to use the target object, not how to bind to it. Regards, Kjell > > But they [Monikers] didn't catch on properly because they > were so incredibly complicated! Programmers often asked > themselves: why not just directly use a file path or a URL - > or a table? Why do I have to perform 27 steps just to locate > an object? > > Truth be known, I've just implemented a set of polymorphic > Moniker objects in a current distributed project of mine and > I'm beginning to realise that it actually hasn't simplified > my design pattern much at all.. (Quite the opposite, in > fact.) But despite this, I think Monikers (implemented in a > programmer-accessible fashion) are a natural part of any > system where things need to be elegantly located and accessed > - such as .NET remoting. >
