lol, yeah i figured i'd be screwed whichever way i go until the code is
refactored into separate components. at this point i'm just trying to get
some unit tests going!
anywho, here's a clean way of getting around the TFF keeping references for
those interested:
public class AutoReleaseInterceptor : IInterceptor
{
public void Intercept(IInvocation invocation)
{
object instance = null;
try
{
invocation.Proceed();
instance = invocation.ReturnValue;
}
finally
{
var factory = invocation.Proxy as IGenericFactory;
if (factory != null && instance != null)
{
factory.Release(instance);
}
}
}
}
2010/4/13 Krzysztof Koźmic (2) <[email protected]>
> inline:
>
> On 13 Kwi, 16:28, bling <[email protected]> wrote:
> > i've been playing around with different ideas and i've yet to come up
> > with the best one that doesn't leave a sour taste in my mouth (when
> > applied to the codebase in question).
> >
> > IFactory<T>
> > - pros: single ctor injection, can create any type
> > - cons: is not clear what the actual dependences are. basically
> > another way of pretending to be a service locator.
>
> yeap, that's just smart impl. of service locator (which I consider to
> be an antipattern when IoC container is involved).
>
> >
> > IConcreteImplementationFactory
> > - pros: explicit definition of dependency
> > - cons: if i keep this up, when i'm "done" my constructors will have
> > about 20 args
>
> Well, 20 args, does not mean there's something wrong with that
> approach ;)
> it means your component in question is farm from doing just one thing.
> As you refactor the code and split the responsibilities the arguments
> count
> will go down as well. That's what I like about .ctor injection - it
> makes SRP
> violation very obvious.
>
> >
> > Func<T, TResult>
> > - pros: flexible, and can hook in with the anonymous arg overloads
> > for custom creation. can be explicit/implement depend on generic
> > version or not.
> > - cons: 20 properties instead T_T
>
> plus it's yet another form of SeviceLocator. You may however use
> closed delegate instead (Func<IDao>)
> BTW, if you don't mind to testdrive beta software you may want to
> checkout my spike that adds delegate-based factories to Windsor
>
> http://code.assembla.com/kkozmic/subversion/nodes/Garage/Castle.LightweightFactoryFacility
>
> It does not use nested container, so if your base container uses
> NoTrackingReleasePolicy your components released via delegate won't be
> tracked either.
>
> Note however that this is not official part of Castle. At this point
> it's an experiment, and while I'm happy to answer your questions about
> it and listen
> to your feedback I take no responsibility whatsoever if if blows your
> app up. ;) Use at your own risk.
>
> Krzysztof
>
> >
> > (and no, rewrite is not an option...)
> >
> > so far i've been leaning more and more towards the Func way of doing
> > things, which requires that the container doesn't keep track of
> > burden. if u got any ideas it'd be appreciated ;-)
> >
> > On Apr 13, 7:03 am, Krzysztof Koźmic (2) <[email protected]> wrote:
> >
> > > Remember that not-releasing the components (when using NoTracking
> > > policy) has its own set of problems (dependencies (of dependencies)
> > > are not properly cleared).
> > > If you're sure you want to do it, the way outlined above should do the
> > > trick for you. I'd also try to make your factory interface more
> > > specific,
> > > i.e. IDal CreateDal() instead of T Create<T>().
> >
> > > Krzysztof
> >
> > > On 13 Kwi, 15:47, Bailey Ling <[email protected]> wrote:
> >
> > > > hehe...
> >
> > > > IMO i share the view that transients should not be tracked by the
> container,
> > > > but also, that i'm in a position where i have an extremely large
> legacy
> > > > codebase violating every principle of SOLID, backed with no unit nor
> > > > integration tests! (think 10,000 line files with 1,000 line methods,
> x200
> > > > files). in this scenario, having no burden tracking is closest to
> the
> > > > original implementation. it's hard enough as is avoiding a service
> locator.
> >
> > > > for cases where it needed to hit the database, i was using the TFF
> like
> > > > this:
> >
> > > > using (var dal = _factory.Create<IDal>())
> > > > {
> > > > // dal.GetDataSet();
> >
> > > > }
> >
> > > > unexpectedly, every time i hit the database i leaked a dal instance.
> in
> > > > other cases, i was rerouting the creation of user sessions to the
> factory.
> > > > that one's a different story as sessions are stored all over the
> place and
> > > > cannot easily be predicted how they're cleaned up.
> >
> > > > 2010/4/13 Krzysztof Koźmic (2) <[email protected]>
> >
> > > > > and why are you using NoTrackingReleasePolicy in the first place?
> >
> > > > > --
> > > > > 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]<castle-project-users%[email protected]>
> <castle-project-users%[email protected]<castle-project-users%[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]<castle-project-users%[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.
