| 4/9/2006 4:07:47 PM |
Let me say that I am learning plenty by going through your code. Thank you--genuinely!--for sharing it. Now, on with my question.
The static constructor of your Manager class calls the Types.LoadAssemblies method, which forcibly loads all of the assemblies.
First, why forcibly load them? Doesn't reflection work with assembly metadata, which means the assemblies don't actually need to be loaded?
Second, why does the Manager call the Types.LoadAssemblies method? The only code that then makes use of that Types class is down in the catch block of the Manager's constructor, so taking the LoadAssemblies step may very well have been unnecessary. Wouldn't it be better to not have the Manager call LoadAssemblies, but have the Types class call its own LoadAssemblies method, loading them only if necessary?
Third, wouldn't loading all of the assemblies in the Bin folder be a relatively slow process? Shouldn't you lock a private static variable so that two or more simultaneous users would not force repeated loads of the same assemblies? |
| 4/9/2006 4:17:36 PM |
Most of the "why" can be found in this post. I'll readily admit this is an ugly hack, and now that I'm adding optional support for full type names that include the assembly information in the ORMapper (work still in progress with other additions), maybe I can remove this code in the future. Is it slow? Assuming that you aren't putting lots of unnecessary assemblies in your bin folder (if any) then it should be a mute point since its just a question of timing, and since it only occurs on the app startup it should matter even less. Finally, at least in my implementation, this is only called from a static constructor, so it is guaranteed to only execute one time, although I agree that this is an implementation assumption that could be cleaned up possibly, although I would also want to investigate how the .net assembly loader actually works to avoid using locks if possible.
Thanks, Paul Wilson
|
| 4/9/2006 7:15:08 PM |
Okay, that all makes sense (though it is clear that I need a better understanding of static members).
Thank you, once again, for your explanation. |