On Thu, Jan 21, 2010 at 3:59 PM, hammett <[email protected]> wrote:

> I see. Still, you can achieve the same behavior by a domain specific
> code, instead of relying on the container behavior. I know it can be
> convenient to depend on the container, but not necessarily the best.
> What if you were to use a different container instead of windsor? It's
> probably very dependent on Windsor, and I'm not sure it's a good
> thing..
>

Yup, you are correct.  In fact I already have that capability because
views can be obtained dynamically vs ctor dependency.  The main issue
about taking on full responsibility of release is knowing if the container
serviced the views or the view were resolved externally and passed.  Thats
what is nice about container doing the work.


>
> IoC containers should be all about isolation and decoupling, but if
> you find yourself depending on its behavior, then you're tied again
> :-)
>

definitely

>
>
> On Thu, Jan 21, 2010 at 1:50 PM, Craig Neuwirt <[email protected]> wrote:
> >
> >
> > On Thu, Jan 21, 2010 at 3:45 PM, hammett <[email protected]> wrote:
> >>
> >> So you have expensive objects that are recyclable?
> >> Care to share more about them?
> >
> > I have been developing a framework I tentatively named Monorail D (name
> > subject to discussion).
> > It started out as tribute to the wonderful Castle Monorail but applied to
> > the desktop (hence D) scenarios.
> > It is actually very very much based on the Monorail way of things and
> > supports many of the concepts
> > Its view independent so it will (when done) support WinForms, WPF,
> > Siliverlight,....
> > Of course, a primary aspect is views and they are expensive to create.
> > The Controllers are transients, but the views are pooled (by default).
> The
> > Component Burden has been
> > an absolute savior in this area and works beautifully to release/recycle
> the
> > views.
> >
> > cheers,
> >  craig
> >
> >>
> >>
> >> On Thu, Jan 21, 2010 at 1:38 PM, Craig Neuwirt <[email protected]>
> wrote:
> >> > I depend on Component Burden since I use Pool lifestyles.  Why do you
> >> > want
> >> > to remove that.  It's a common approach when you have expensive
> >> > components.
> >> > In my case, its an desktop MVC infrasttructure.
> >>
> >> --
> >> Cheers,
> >> hammett
> >> http://hammett.castleproject.org/
> >>
> >> --
> >> 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]<castle-project-devel%[email protected]>
> .
> >> For more options, visit this group at
> >> http://groups.google.com/group/castle-project-devel?hl=en.
> >>
> >>
> >>
> >
> > --
> > 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]<castle-project-devel%[email protected]>
> .
> > For more options, visit this group at
> > http://groups.google.com/group/castle-project-devel?hl=en.
> >
>
>
>
> --
>  Cheers,
> hammett
> http://hammett.castleproject.org/
>
> --
> 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]<castle-project-devel%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>
>
>
>

-- 
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.

Reply via email to