Hamilton Ver�ssimo de Oliveira wrote:

De: Berin Loritsch [mailto:[EMAIL PROTECTED]


<snip type="realization of importance for dependencies"/>


So the dependency information suddently appear to me as a must have...


Yep. That's what we have found.



Yeah. Its nice to have some AOP kind of functionality. Unfortunately transparent proxies in .Net is only available to classes that derive from MarshalByRef. I think it's very intrusive to force one to derive from MarshalByRef and lost his only oportunity to implementation inheritante (I know there is work arounds, anyway it's ugly)


Yuck. Anyway, that is a topic for later discussion. The first step is to pass the instance by interface.

"praying" for disposal--as much as possible we want to avoid "prayer"
as a design constraint.  Don't get me wrong, I am a regular practicer
of prayer, but it has its place. ;P  The container is responsible for
properly disposing of components when they are no longer needed.


Sure. I was kidding. What's frightening me is instanciate the
dependencies and pass on their ownership to the component. Then we lost
control. If the component implementation doesn't dispose his
dependencies properly, we're lost.

First, the container never relinquishes control or ownership. It merely lets components use each other in a managed way.


To ilustrate my fears, imagine that:

- Component A depends on Component B
- Container realize that it needs to instantiate A, before it
instantiante the component B (lifestyle Pooled) and initialize it's
lifecycle
- Container instantiate A and pass on component B


In order to make component B available to pooling, his factory needs a
message telling the use of component B instance is over. Who call this
message? Should be the container. How the container knows component A
terminates its use of dependencies? Ok, it will know when it dispose
component A...


Is that the idea?

Let's worry more about the simple case first. The simple case is singletons (one instance of a component per container).

This is where a proxy can come in handy.  The proxy would be able to have
"garbage collection" policies for a component instance, or do a lookup/
release behind the scenes for each method call.  That would allow you to
only have the instance of the component when it is needed, and still allow
the container to have complete control.

Granted this is a complicated way of doing things, but as always focus on
the simple stuff first.

Right now in Java land, we have a lookup() and release() cycle for components
being looked up.  All that is done with the associated LookupManager (AKA
ServiceManager).  However, you probably have already noticed the absense of
the release() method in the C# code.

The reason is that I wanted to make the system as unobtrusive to the client
(code using a component) as possible.  So for the time being, let's focus on
the simple (singleton) lifestyle.  If we need something else, we can address
it then.





I am definitely willing to help you through the hurdles. So that I

can


help bridge the gap, where are you in your understanding of how containers work?


I appreciate that. I thought I knew how a container works by my
experience using Fortress.. I was wrong :-)


As a simple point a view a Container should handle different lifestyles
exposed by components and offers a few common set of services as
configuration and logging. The entry point for a Avalon based
application is the ServiceManager implementation, as it enable look ups
by roles.


After a sucessfull lookup the container should instantiate the
implementation and deals with the lifecycle. Then we enter in the
implementation arena. My understanding of Fortress show me that there is
a ComponentHandler that holds a ComponentFactory. Exception for
ComponentFactory that seems to implement both concerns.  :-)

After using a component/service, a correct client implementation should
return the instance to ServiceManager, that should return it to
ComponentHandler.

What I've missed?


hammett




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





--

"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