yeap,
If you want to do interception you'd be better of to intercept Dispose,
since you're taking advantage of C#'s 'using' statement
similar to what I did here:
http://kozmic.pl/archive/2010/01/27/transparently-releasing-components-in-windsor.aspx
or here:
http://kozmic.pl/archive/2010/03/11/advanced-castle-windsor-ndash-generic-typed-factories-auto-release-and-more.aspx
please treat it as temporary workaround :)
Krzysztof
On 2010-04-13 19:21, Bailey Ling wrote:
spoke too soon. scrap that idea...you'll get a disposed instance.
2010/4/13 Bailey Ling <[email protected]
<mailto:[email protected]>>
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]
<mailto:[email protected]>>
inline:
On 13 Kwi, 16:28, bling <[email protected]
<mailto:[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] <mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>
> > > > .
> > > > To unsubscribe from this group, send email to
> > > > [email protected]
<mailto:castle-project-users%[email protected]><castle-project-users%[email protected]
<mailto: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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto: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.
--
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.
