I think the Moniker interfaces were a little hard to use, and not well explained on MSDN. I think Monikers would have caught on if there were a lot of concrete examples on MSDN and Microsoft had pushed them a little bit. Some recommended syntax and available parsing routines would have helped. Once I learned how to write monikers, it became quite easy.
Who can we lobby to ask for a moniker system for dotnet? Doug > -----Original Message----- > From: Kjell Arild Tangen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2003 11:39 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Constructing Objects From Strings in > dotnet > > > 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. > > >
