I've got one library which registers a component like this container.Register(Component.For<IServer>().ImplementedBy<Server>().LifeStyle.Transient)
In this way, users of IServer don't have to know about (or even include as a reference) the concrete implementation of Server. But when push comes to shove, there are some changes in registration the final application may want to make. For instance, a web application may want to register it to start on startup (e.g. with the startable facility), while a unit test may never want to resolve it at all. It almost seems like the library supplying Server is doing a partial registration, "anyone who wants an IServer should come get a Server". But it seems like other folks will want to attach more information to the configuration, like "when my web app starts up, start my IServer instance". (In fact, this particular server instance won't even resolve properly until another dependency is registered, one which the raw Server provider may not be able to supply) The easy answer is to resolve this object and Start() it manually in the startup routine (e.g. global.asax) Am I thinking about this in the wrong fashion? -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
