hammett wrote:
----- Original Message -----
From: "Berin Loritsch" <[EMAIL PROTECTED]>


Are you referring to the lifecycle of the container itself?  It's
not clear.  It looks as if you are wanting to duplicate the Lifecycle
Extensions which we have in Java.


The same fuctionality implemented in a different way.


1) A container is responsible for the life of a component, and satisfying
   any and all dependencies.


Sounds simple, but is definitely not :-) Let's go a step further:

- in the initialization phase the assemblies are checked and avalon
components/services are discovered. Every information a component exposes
about itself through Attributes goes to to a ComponentEntry (something like
MetaInfo in Fortress)
- by now we have the dependencies list/lifestyle/config/logger name for the
component
- sometime later, someone make a look up for the component that has
dependencies. What shall we do at this time?

  * Simple situation - the dependencies doesnt hold another dependencies
  * Complex situation - the dependencies hold another dependencies
  * Evil situation - the dependencies depends each other (A depends on B
which depends on A)


General guidelines:

* Never allow circular dependencies with components.  They don't work, and
  if two or more components are so intertwined, they should be merged into one
  component.

* Components can have dependencies on components with dependencies.  Don't
  limit the user.

* Not all dependencies are required--you can choose how you want to handle them.
  (i.e. load if available, or never load unless explicitly told to do so).

Check out the Directed Acyclic Graph utilities in Fortress (**.fortress.**.dag).
Porting that to C# will help you find violations of the first guideline, as
well as help you order your dependencies so that they are loaded and disposed of
in the proper order.

Considering that we have treaded this ground several times before with the Java
side, you definitely have some good resources available to you.



Got it. I will deffer the lifecycle extensions idea.. Anyway I tried to solve the relation:

- Component has a ComponentHandler which has a ComponentFactory

by using a LifestyleManager to centralize invocation of lifestyle methods.

Lifestyle is more like "transient", "singleton", "pooled", etc. Lifecycle is the initialization, destruction, etc.

--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
                - Benjamin Franklin


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to