spoke too soon. scrap that idea...you'll get a disposed instance.
2010/4/13 Bailey Ling <[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]>
>
> 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.
