The Elephant and the Silverlight

Thoughts and analysis of Silverlight for business applications

Page List

    Updated ApplyState/ExtractState Library

    Export more blog entries this week. I will be putting up my guide to the major new features after todays keynote.

    In the meantime, here is an updated ApplyState/ExtractState refactored to use the EntitySet instead of the EntityList. I will put up a VS2010 version as well tonight.

    RIAServicesContrib2008.zip (235.60 kb)


    Tags: , ,
    Categories: RIA Services | RIA Services Contrib
    Posted by ColinBlair on Wednesday, November 18, 2009 10:27 AM
    E-mail | Kick it! | DZone it! | del.icio.us
    Permalink | Comments (5) | Post RSSRSS comment feed

    Comments

    The Elephant and the Silverlight

    Friday, February 26, 2010 2:05 PM

    trackback

    ApplyState and ExtractState with RIA Services Contrib

    ApplyState and ExtractState with RIA Services Contrib

    Merijn Netherlands

    Thursday, July 08, 2010 3:20 PM

    Merijn

    Hi Colin,
    Thanks for these useful functions. Can you comment on two questions I have about the implemetation?
    1) In "ApplyState" you throw an exception when entity.EntityState != EntityState.New && originalState == null. However, EntityState can only be "New" iff it is contained in a context. So, if I create a new entity (e.g., new SomeEntity()) and then call ApplyState (e.g., to make it a clone of some other entity), I get this exception since I did not add the newly created entity to my context. In this case EntityState equals "Detached". Questions, is this check really needed? And if so, shouldn't it be changed into something like "(entity.EntityState != EntityState.New && entity.EntityState != EntityState.Detached  && originalState == null"?

    2) In "GetDataMembers" you include "BindingFlags.DeclaredOnly" in bindingAttr. However, this seems to exclude base class properties. So, in case of cloning, the result is a partial clone since inherited members are not cloned. This seems not to be correct. Or is this intensional?

    Any clarification would be greatly appreciated!

    Thanks!


    ColinBlair United States

    Tuesday, July 13, 2010 10:26 AM

    ColinBlair

    @Merijn good questions.

    1) The only time that the OriginalState should be null is if the entity is in New state. The rest of the time, it needs to be supplied. In the example you gave, a detached entity, you should be suppling only the OriginalState and a null ModifiedState. If you pass both to a detached entity, the result is the same as if the modified state was supplied as the original state with a null modified state. This is because change tracking is disabled for a detached entity so the modified state just overwrites the original values. I could throw an exception if the modified state is supplied for a detached entity but I flipped a coin and decided not to.

    2) The ExtractState and ApplyState are based on the actual ExtractState and ApplyState that are built into the entities themselves (they are internal currently). The original code came from an offline storage example from a very early release of WCF RIA Services although it has modified since then through consultation with the RIA Services team. I will check with the team, but I think you can safely remove the check for DeclaredOnly to get support for inheritance. I think that check is left over from when RIA Services didn't support inheritance.

    Merijn Netherlands

    Wednesday, July 14, 2010 10:27 AM

    Merijn

    Hi Colin,
    Thanks for your answers.
    I think I understand your answer on my first question, but in your example about entity cloning you do exactly the opposite, if I'm correct:

    Person newPerson = newPerson();
    newPerson.ApplyState(Nothing, existingPerson.ExtractState(ExtractType.ModifiedState);

    (taken from www.riaservicesblog.net/.../...vices-Contrib.aspx)

    Here you do not supply an original state, but you _do_ supply a modified state. The newly created person is clearly not yet attached to a context. So, if I understand you correctly, the code example is incorrect and will raise an exception. Shouldn't it be changed to:

    newPerson.ApplyState(existingPerson.ExtractState(ExtractType.ModifiedState, Nothing);


    Do I also understand correctly that for cloning I must need to know if an entity is attached to a context in order to
    know which arguments to fill in?  For example, continuing on the previous example, if I now add newPerson to my context and then make yet another clone, I should do it like this:

    newPerson.ApplyState(Nothing, existingPerson.ExtractState(ExtractType.ModifiedState);

    Do I understand this correctly?


    ColinBlair United States

    Wednesday, July 14, 2010 12:07 PM

    ColinBlair

    Yes, the example is wrong and you are the first person to notice after well over a year. I will take it a step further and say that cloning an entity requires using both the Original State and the Modified state. If you are not using both then you are only making a copy of one of the two states of the original entity. I will get the examples updated.

    I think the second part of your question you are creating a new entity that has a copy of the original values, in that case you are correct.

    Add comment


    (Will show your Gravatar icon)

      Country flag

    Click to change captcha
    biuquote
    • Comment
    • Preview
    Loading