Well i think i got the answer myself, but just to share information and to get confirmation im right about this :) I've found a page with information about the differend types of constructing, my thanks go to Haibo.
http://blogs.msdn.com/haibo_luo/archive/2005/11/17/494009.aspx
Gladly CSLA has a helper class called "MethodCaller" which is public :)
It seems that MethodCaller.CreateInstance only allows parameterless constructing.
So it can be only used instead of Activator.CreateInstance when constructing objects with a parameterless constructor.
So which approach does MethodCaller.CreateInstance use behind the screens?
If u follow the link and look at the code behind MethodCaller it seems to use the "DynamicMethod + Delegate approach".
I'll be using MethodCaller.CreateInstance alot, since i'm using the objectfactory model. Which requires to create objectfactory's and business objects ourself.
PS: Only use MethodCaller.CreateInstance for objects that are created often, since it creates delegates and cache them in memory.
Now i do have a question:
Why isn't CSLA using MethodCaller.CreateInstance instead of Activator.CreateInstance in several situations?
FactoryDataPortal.FactoryLoader
(IObjectFactoryLoader)Activator.CreateInstance(Type.GetType(setting, true, true));
Csla.DataPortal
return (DataPortalClient.IDataPortalProxy)Activator.CreateInstance(_proxyType);
Much of the answer is the same as it was in this post:
http://forums.lhotka.net/forums/permalink/32390/32391/ShowThread.aspx#32391
And (though this is a little dated now) this article is still largely valid, and certainly applies for the creation of things like the factory object:
http://www.lhotka.net/Article.aspx?area=4&id=4320e7f2-dd14-4928-b552-4eb0cb82cd68
The "Why" i understand now, and u are right, it's called way too less, thanks for the link (even if it's outdated)
I'm just glad that MethodCaller.CreateInstance() is public ;)
Copyright (c) Marimer LLC