I have (pre) released SnapDAL, the data access helper and Factory I use in a large majority of code I write. There are many many changes in this release and I will probably hit these in a series of short blogs. But in addition to the powerful new features to support unit testing, the deep under the covers change was that the DataFactory class is now actually based on the same factory as the factory class was. I think the reason Dan Fox didn’t do that in the first place was to squeeze out some performance, because we all know that factories slow down your code, right??
Wrong! Hidden in this release was a performance test based on a CodeProject article called NPerf. It shows that while there is a small sacrifice for using the factory approach in SnapDAL, it is almost imperceptible. Please note that the first graphs are not executing queries and so the overall time is less than the 5ms on my average system.
There is a reason SnapDAL gets this performance though. The technique used to implement the factory as flexibly as possible and still maintain performance is this.
– instances are first put in a cache after construction from Activator.CreateInstance
– when the factory returns and instance of the IDbCommand, Connection etc., it returns a clone of the cached copy.
It is this caching and cloning that turns out to be so efficient. Now, having the cache also opened up a large number of other possibilities for this factory that have become the basis of the mock functionality. But more on that later.