Daniel Krieg wrote:
I am attempting to implement my own Container and have some questions about Inversion of Control patterns. I am attempting to create a Container that manages a single component type at a time. The contained components may be associated with other components held within other container instances. The Container should be responsible for resolving these dependencies within the ServiceManager for the component. Correct so far?If I understand you corectly, I think your describing something close to the notion of a component "handler"(Fortress) or "appliance" (Merlin). Service resolution by a ServiceManager implementation is one approach to depedency resolution (this is basically what the Fortress system does).
Now, the Container is also a component with associations to other components.
Yep.
Is it violating IOC if the Container-associated components are made available to the child components not within the ServiceManager but within the Context?No, it's not an IOC violation. The ServiceManager and Context are simply artifacts provided by a container to a component (i.e. the vehicle through which the resources are provided).
After all, the Container-associated components are implicit services to the Contained components and therefore should not need to be declared as a dependency.In general I disagree with the above. Container associated components are the concern of the container and that does not imply that they are a concern of a particular component. If you choose not to declare the dependency, then in effect, you are defining components that make explicit assumptions about their containment environment. This leads to non-portable components.
What this really means that a child Context has indirect access to the contents of its parent's ServiceManager. Does this seem reasonable or am I missing the boat somewhere?It is reasonable providing you keep in mind that this is implicitly limiting your components to that containment policy.
I think a component's ServiceManager should only provide peer relationships and components related to a component's Container should be part of a component's Context.This is consistent with the A4 notions of context and service separation. Under my own implementation components I've largely stopped using ServiceManager and Context separation in favor for a single locator abstraction. The reason being the distinction between what is a context and what is a service is largely artificial and driven by implementation concerns. Eliminating this destination results in reduced code and higher flexibility in the component design.
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
