On Wed, 2009-06-17 at 14:39 +0200, Giacomo Tesio wrote: > First becouse the member has no state by itself, and the constructor > have nothing to do with it (AFAIK)
Alas, you're wrong. From uncommitted messages, I saw that most of the Init() call overhead was due to the mappingSource.GetModel(GetType()) call at the end of Init(). > Second becouse (with DbLinq only) you could also have entities > directly accessed by the GetTable<T>() method. The overhead of DataContext.GetTable<T>(), from reading the source, is from Activator.CreateInstance() (known to be slow) and from Mapping.GetTable() (not sure how long that will take). Everything else in that method shouldn't be horrendously long. > What we could improve in some way would probably be > 1. Vendor load and creation Not sure that that this can be improved upon much, given that it's based on Reflection. We can only make it so much better without requiring the use of the DataContext(IDbConnection, IVendor) constructor (which is something I can't rely upon). > 2. that fucking ObjectFactory... :-D Anyone know of an MIT/X11 IoC container? We might want to consider using a real IoC container instead of the ObjectFactory wanna-be... Though do we really need IoC functionality at all? I'm dubious of its use here... - Jon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" 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/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
