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