Parent child relationships....

Parent child relationships....

Old forum URL: forums.lhotka.net/forums/t/7008.aspx


Nemisis posted on Wednesday, May 27, 2009

Hi everyone, hope you are all well. I have recently upgraded from v2.1 to v3.6 and very happy with it so far, but i have a question, more about design rather then csla.

I have a parent list called TeamList.  TeamList holds Team objects, but each Team object has a property called TeamList, so basically a Team can be within another team and have team as children.

Now, my problem is that if i need to move a team to a different parent, i would call Remove in the list and then insert, but csla now thinks that the objects needs to be deleted in the database and then added as a new item.  Now all other tables that use that Id are incorrect.

Has anyone come across anything like this before?  How would people suggest going about this?  Is it bad practice to store the actual parentId against the object as another property, especially since if i update this the object will still be in the wrong place, unless i refetch the data.

Another option, is to do the Remove and Insert option, and then create a custom property that Marks the object as swapped, which looks like this.

        Protected Friend Sub MarkSwapped()
            MarkNew()   ' so not IsDeleted
            MarkOld()   ' so not IsNew
            MarkDirty() ' so IsDirty
        End Sub

Is this ok?  This would mean that the list is in the correct order, before saving and when saving, the object is updated ONLY, rather then deleted and added.

If anyone has a better way to do this let me know

rsbaker0 replied on Thursday, May 28, 2009

Nemisis:
...Now, my problem is that if i need to move a team to a different parent, i would call Remove in the list and then insert, but csla now thinks that the objects needs to be deleted in the database and then added as a new item.  Now all other tables that use that Id are incorrect...


Maybe this isn't the right way to think of this from the CSLA perspective, but what you are doing here really isn't a Remove but instead is simply changing the parent property.

I'd think there are several ways to do this, but one possibility would be to implement a specific method for this purpose that doesn't use the Remove method but instead updates the relationships directly (perhaps a CommandBase derived object). I think you are on the right track that refreshing the original list is the correct way to "remove" it from the original list.

dmnc replied on Friday, May 29, 2009

You could have a MoveTo method on you Team object that delegates the movement to the parent TeamList collection and marks the moved Team object as dirty. In the TeamList collection clone the Team object, remove it from the collection and deleted list and add it to the new parent.

Public Class Team
    Inherits BusinessBase(Of Team)

    Public Sub MoveTo(ByVal target As Team)

        Dim movedTeam = DirectCast(Me.Parent, TeamList).MoveTo(Me, target)
        movedTeam.MarkDirty()

    End Sub

End Class

Public Class TeamList
   Inherits BusinessListBase(Of TeamList , Team)

   Friend Function MoveTo(ByVal sourceTeam As Team, ByVal targetTeam As Team) As Team
 
        Dim clone = sourceTeam.Clone()

        Me.Remove(sourceTeam)
        Me.DeletedList.Remove(sourceTeam)

        targetTeam.TeamList.Add(clone)

        Return clone

    End Function

End Class

Nemisis replied on Sunday, May 31, 2009

Thanks for both replies, but i think i like the MoveTo Sub and Function best as i think it suits me more.

I have one question about this though....

This works perfectly for moving teams to other teams, but since TeamList is the parent object, and a team can NOT have a parent (thus it would be in the root TeamList), how can i move a team  that has a parent, to the root teamlist?  I guess i would need some sort of reference to the root team?  I dont think i can use the Parent property?

Thanks again

Nemisis replied on Sunday, May 31, 2009

Never mind, i have created a second function/sub that takes a list parameter.

Thanks again

Copyright (c) Marimer LLC