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. IConcreteImplementationFactory - pros: explicit definition of dependency - cons: if i keep this up, when i'm "done" my constructors will have about 20 args 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 (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.
