Hi i wonder which one is more effective? here is my scenerio:

i have two methods, first one is called LoadPersonalData, second one is called LoadPreviewData.

they both get userid as a parameter. they both create a userentity and addressenitty by using the provided userid. cant conbine them cause they load data on two different usercontrols.

in one place, i have to call both methods back to back: loadpersonaldata(userid); loadpreviewdata(userid);

the question is: is it more effective to create user and address entities before calling the methods and provide them as parameters so they wont be created again in the second method OR is it better to use userid as the parameter since the created entities will be put in memory after the first method and wont be fetched again?

thanks -shane

Hi Shane,

When you call both methods back-to-back, it is going to the database twice. Even if you use a Context object to cache, you're still going to the database.

It really depends what you want to do.

If you want both screens viewing/editing the same User object at the same time (meaning, changing User.Name on one screen automatically changes the other screen) - then yes, you can pass the actual Entity to both screens instead of the ID.

However, if you want the screens viewing/editing the same User object, but do not want changes to be reflected in the other screen - then you need to Clone the User object, and pass the cloned User object to the second screen. This way they'll be editing different instances of the same User object. And you only went to the DB once.

So, to simplify, I think you have 3 options:

• Pass by ID (Loads Entity from DB several times)
• Pass by Entity, Shared Entity across 2 screens (Goes to DB once)
• Pass by Cloned Entity, Entities are independent of eachother. (Goes to DB once) Hope this helps!

Ryan

thanks Ryan, one screen will view, other will edit. i think i ll go with passing the entity itself.

how do you pass a cloned entity? just curious.

thanks again -shane

rdhatch wrote:

Hi Shane,

When you call both methods back-to-back, it is going to the database twice. Even if you use a Context object to cache, you're still going to the database.

It really depends what you want to do.

If you want both screens viewing/editing the same User object at the same time (meaning, changing User.Name on one screen automatically changes the other screen) - then yes, you can pass the actual Entity to both screens instead of the ID.

However, if you want the screens viewing/editing the same User object, but do not want changes to be reflected in the other screen - then you need to Clone the User object, and pass the cloned User object to the second screen. This way they'll be editing different instances of the same User object. And you only went to the DB once.

So, to simplify, I think you have 3 options:

• Pass by ID (Loads Entity from DB several times)
• Pass by Entity, Shared Entity across 2 screens (Goes to DB once)
• Pass by Cloned Entity, Entities are independent of eachother. (Goes to DB once) Hope this helps!

Ryan

Hi Shane,

Glad to be of help.

Here is the simple code for cloning an entire Entity graph. It comes in useful for Undo/Cancel. Because LLBLGen Pro supports serializing - you simply serialize & unserialize your object.

    ''' <summary>
    ''' Clones an entire Entity Graph - Used for Undo RestorePoints
    ''' </summary>
    ''' <param name="myEntity"></param>
    ''' <returns></returns>
    ''' <remarks></remarks>
    Public Shared Function CloneEntityGraph(ByRef myEntity As IEntity) As IEntity
        'Serialize Entity
        Dim myMemStream As New System.IO.MemoryStream
        Dim myFormatter As New System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
        myFormatter.Serialize(myMemStream, myEntity)

        'Deserialize Entity (new instance of same Object ID)
        myMemStream.Seek(0, IO.SeekOrigin.Begin)
        Dim copyEntity As IEntity = CType(myFormatter.Deserialize(myMemStream), IEntity)
        myMemStream.Close()

        Return copyEntity
    End Function

Hope this helps!

Ryan

PS. There are much more complex uses of Cloning, such as a RecursiveCloneAsNew() method I've written - which will clone an Entity and all of it's recursive children as New entities, without marking its recursive Parent entities as New. It gives you the option to RequirePrefetch or AllowLazyLoad, and instead of cloning its recursive Parent entities it will even retain pointers to the existing instances of all Parent entities.