This project is read-only.

DI and Pool<T>

Feb 7, 2011 at 3:26 AM

An issue with Pool<T> is that it requires managed objects to belong to classes with a parameterless constructor. This of course means problems for anyone who wants/needs to pool objects making use of dependency injection. What I'd like to suggest is that Pool be changed to allow for registration of factory methods which will do the actual object construction when needed.

I offer as an example, this CodeProject article which presents a pool manager which makes use of Func delegates as the factories, on a per-type basis. While the manager presented in that article may be a bit overweight for the purposes here, the idea at least of having a registry of delegates for object creation is a fairly good one, in my opinion, and providing the ability to have factories for Pool would certainly make it fit better with the rest of Nuclex given its DI-friendly design.

Feb 7, 2011 at 3:29 AM
Edited Feb 7, 2011 at 3:30 AM

BTW, how soon to new release? EDIT: Never mind, just saw front page.

Feb 7, 2011 at 9:20 AM

Will take a look at it! I have mostly combined the Pool<T> with the flyweight pattern and thus didn't need non-default constructors, but I like the idea!

Looks like a lot of bugs have slipped into this release (maybe I should rename it to R1323 "Bugfest" :D) - I'll hold out a little bit longer and see what other bugs might come up, then do another pure bugfix release! Maybe by the end of this week.

Btw, you can always find up-to-date builds with fixes for all reported bugs here:

Feb 7, 2011 at 7:35 PM

Well, the Pool in SVN still requires "ItemType : class, new()".

The object pool class I'm currently using allows for Func<ItemType> factories, and I'm looking at making it support management of subtypes of whatever ItemType it's used for. (Easier to juggle a single pool, rather than one per pooled class.) Both of these concepts I picked up off that article; originally my pool was similar to the one currently in Nuclex.

Will you be checking in the new Pool some point soon? Would like to see how it works compared to the current one.

Feb 7, 2011 at 10:20 PM

Patience! :) I just posted the daily builds link in response to your release question - I haven't even touched the Pool class yet.

The Func<T> concept seems nice, but I can't quite warm up to the pool for all types idea - from my point of view, it only adds overhead and makes testing more difficult - and if two consumers wanted the same object type with different factory methods/delegates (which could happen if the pool is bound as a singleton instance in the DI container) the whole thing would blow up.



Feb 9, 2011 at 3:21 AM

Oh, I'm not saying that your Pool should be turned into a "one for all types" style pool -- I haven't even decided on that yet for the one I'm using. I was just mentioning that it might be something to think about as well.