Jump to content
McObject Forums
Sign in to follow this  
jmf

Object instantiation on full .net framework

Recommended Posts

jmf    0

Hi,

I've noticed that when using the full .Net version of Perst it creates objects without invoking their constructor. Could you please let me know what the reason for this is?

As we have some logic in the constructors, we would need them invoked. For the time being I've changed the code to actually call the constructor instead of using formatterservices.getuninitializedobject and it seems to work. Was the only reason for using this better performance?

Thanks!

Share this post


Link to post
Share on other sites
perstmco    0

Perst uses formatterservices.getuninitializedobject instead of the standard class constructor because of two reasons:

1. A class may not have a default constructor (constructor without parameter) at all. In this case, Perst will have no idea which values of parameter it has to provide to invoke this constructor.

2. Constructor may perform some actions that are intended to be done when object is actually constructed. But, Perst has to create the object each time it is loaded from persistent storage in memory. It can happen multiple times within a session.

If you are going to use default constructor to initialize transient state of the object when it is loaded, then it is better to override the OnLoad() method.

Share this post


Link to post
Share on other sites
jmf    0

Thanks for the answer. So, as far as I understand, as long as 1 is true (classes have a default constructor) and we don't care about a performance hit necessarily, we could live with using the constructor instantiation also on the full .net framework.

For us the main reason is that we share the codebase between some Silverlight and WPF apps. Since in Silverlight the constructor is called, we have logic there. If we were to move it to OnLoad() then in case we instantiate the objects ourselves, we'd have to additionally call OnLoad() which is not really feasible.

Do you think that this makes sense?

Share this post


Link to post
Share on other sites
perstmco    0

If you wan to use the default constructor for initialization of loaded object, you can change ClassDescriptor.newInstance method.

This is current implementation:

 

        internal object newInstance()

        {

#if COMPACT_NET_FRAMEWORK || SILVERLIGHT

            return defaultConstructor.Invoke(noArgs);

            //return Activator.CreateInstance(cls, true);

#else

            return System.Runtime.Serialization.FormatterServices.GetUninitializedObject(cls);

#endif

        }

 

You can always use defaultConstructor.Invoke(noArgs)

Share this post


Link to post
Share on other sites
yporo    0
On 10/21/2015 at 7:59 AM, jmf said:

Thanks for the answer. So, as far as I understand, as long as 1 is true (classes have a default constructor) and we don't care about a performance hit necessarily, we could live with using the Crazy Bulk stuff  https://deadliftdonkey.com/my-crazy-bulk-review with a constructor instantiation also on the full .net framework.

For us the main reason is that we share the codebase between some Silverlight and WPF apps. Since in Silverlight the constructor is called, we have logic there. If we were to move it to OnLoad() then in case we instantiate the objects ourselves, we'd have to additionally call OnLoad() which is not really feasible.

Do you think that this makes sense?

Nice, that implementation seems to have worked for me too.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×