Thanks for the explanation. Actually supporting precisely this scenario
was the reason for introducing this behaviour in the first place, back
in 2008. And that's because back then Windsor only supported single
service per component. So you could have had PatientTaskCalc registered
either as IPatientTask, or as ITask but not as both. So to workaround
this limitation the ResolveAll ignored what service you assigned to the
component and just looked if its assignable to the type you want.
Later on though (not sure if RC3 had it, but all releases starting with
2.0 did) we introduced concept of ForwardedHandler to allow components
to expose multiple services. That was piggy-backed a bit on top of
existing architecture at the time. In Wawel (codename for Windsor vNext)
that was rebuilt so that multi-service components are now a core concept
in Windsor.
This removes the need for the workaround since now you can be explicit
about your intention:
pContainer.Register( Component.For<IPatientTask,
ITask>().ImplementedBy<PatientTaskCalc>().LifeStyle.Transient);
As a sidenote, you can simplify that registration even further by
relying on scanning, like this:
container.Register(AllTypes.FromAssemblyBla().BasedOn<ITask>().WithService.DefaultInterface().Configure(c
=> c.Lifestyle.Transient));
You would get the same behaviour as you have now, with benefit of being
explicit.
And that implicitness of current implementation is the biggest problem
and driver for change here (mostly to accommodate massively popular
ASP.NET MVC framework with breaks SRP and is a PITA to work with, unless
this is fixed).
Looking forward to your (and others') insight on this.
On 06/03/2011 3:59 AM, [email protected] wrote:
Hi Krzysztof,
one of the scenariois where i use this is the following:
The application is extendable with any plugins. A costumer has also
the ability to extend the application with his own plugins.
The base for such plugins is a framework wich defines the architecture
and some basic interfaces and classes so that the plugins
can integrate properly. One of the reasons for user defined plugins
are Task that could be started by hand or in a chronological
order at defined points in time. So we provide Task interfaces for
specific parts of the application (IPatientTask, IAppointmentTask and
so on).
For any other Task not associated with a specific part of the
application, simply the ITask interface could be used. During startup
the app searches
for plugins and loads them. After that all plugins are being searched
for known interface implementations to register them with the container.
In short it does something like this:
pContainer.Register(
Component.For<IPatientTask>().ImplementedBy<PatientTaskCalc>().Named("p_calc").LifeStyle.Is(Castle.Core.LifestyleType.Transient)
);
pContainer.Register(
Component.For<IPatientTask>().ImplementedBy<PatientTaskMidnight>().Named("p_midnight").LifeStyle.Is(Castle.Core.LifestyleType.Transient)
);
pContainer.Register(
Component.For<IAppointmentTask>().ImplementedBy<AppointmentTaskMonth>().Named("a_month").LifeStyle.Is(Castle.Core.LifestyleType.Transient)
);
pContainer.Register(
Component.For<IAppointmentTask>().ImplementedBy<AppointmentTaskBack>().Named("a_back").LifeStyle.Is(Castle.Core.LifestyleType.Transient)
);
In the application the user can now start a Task or can define, when a
specific Task should start automatically etc. If i want a specific
Task, i ask the container:
IPatientTask[] pTasksP = pContainer.ResolveAll<IPatientTask>(); //2
IAppointmentTask[] pTasksA =
pContainer.ResolveAll<IAppointmentTask>(); //2
To get all the registered Tasks, i ask the container:
ITask[] pAllT = pContainer.ResolveAll<ITask>(); ///all 4
So, in the end for this i need the current behaviour or i have to
change the current application code. Sure there are a lot of other
ways to accomplish this but we decided years ago to do it that way,
because it is simple and it is there :-)
There are other parts, where we use the same approach for instance for
text and document generation etc.
Regards
Am schrieb Krzysztof Koźmic <[email protected]>:
> That's a fair point and that's precisely why I started this thread
and asked for feedback.
>
> So can you shed some more light on the context in which you're
depending on current behaviour and why/if alternative approach (just
registering your components with the service you ResolveAll) would or
would not be feasable.
>
>
>
> I also don't want to derail this thread but i would also be
interested in hearing you scenario in which you're using
RemoveComponent. Perhaps if you could start another thread to discuss
that, that would be great.
>
>
>
> Krzysztof
>
>
>
> On 04/03/2011 11:49 PM, [email protected] wrote:
>
>
> Jason, that may all be true, but I want to use the container as is
and don't want to rethink and rework thinks from release to release.
Now i use ResolveAll and
>
> want it to return all components implementing a specific service no
matter for what else they are registered. Next time i have to build
something new to do this.
>
> Now i use RemoveComponent. Next release it is not available anymore
and i have again to build something new. I don't know , i thought i
simply could use the lib
>
> to simplify my work where i have enough other things to think about.
>
>
>
> Am schrieb Jason Meckley [email protected]>:
>
> > Handler selectors are not a work around, they are how handler
selection should be done. the recommendation on the table fixes a
subtle, implicit bug. creating yet another method on IWindsorContainer
doesn't solve the problem, it solves the symptom.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> > You received this message because you are subscribed to the Google
Groups "Castle Project Users" 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-users?hl=en.
>
> > --
>
> You received this message because you are subscribed to the Google
Groups "Castle Project Users" 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-users?hl=en.
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google
Groups "Castle Project Users" 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-users?hl=en.
>
>
> --
You received this message because you are subscribed to the Google
Groups "Castle Project Users" 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-users?hl=en.
--
You received this message because you are subscribed to the Google Groups "Castle
Project Users" 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-users?hl=en.
