Wishlist item: Add a Copy() method to BusinessBase...

Wishlist item: Add a Copy() method to BusinessBase...

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


cmclernon posted on Monday, November 24, 2008

Hi Rocky,

Just wondering if there are any plans to implement the Copy() method in the near future?

Thanks,

Colm

skagen00 replied on Monday, November 24, 2008

BusinessBase does support Clone(), which makes a copy of the object - are you referring to something else?

cmclernon replied on Monday, November 24, 2008

http://www.lhotka.net/cslanet/WishList.aspx

Yeah, it's item no. 20 on the above wishlist link.  The full description is:

Add a Copy() method to BusinessBase (like Clone(), but with ability to change resulting objects). And cascade call through to child objects.

 

RockfordLhotka replied on Monday, November 24, 2008

Not in 3.6.0, no. I don't have any estimate on a timeline.

cmclernon replied on Tuesday, November 25, 2008

Thanks for the reply Rocky,

I have implemented the FixUpAfterCopy() method you specified in another thread and it works well.  The only reservation I have with it is that it needs maintained so that any newly added childlist's are added to the method.

Regards,

Colm

P.S. I know your todo list must be massive and also everyone has their own wants but I'd just like to add that the Copy() method is high on my wishlist as it would eliminate this maintenance and hence provide a nicer framework experience. :)

rsbaker0 replied on Tuesday, November 25, 2008

I think with managed fields that a reasonably generic or common method to implement this would not be that difficult. I have a need for it myself so I may just post my implementation once I'm happy with it.

Objects with auto-incrementing fields (e.g. identity columns) might need special attention. Depending on how you're saving the new copy, the old values might be ignored anyway even if you left them alone, but it would be best if they are represented the same way a brand new object of the same type would appear.

SonOfPirate replied on Tuesday, November 25, 2008

We've added an ICopyable interface, analogous to ICloneable, with a single Copy() method for this purpose.  In our case, cloning is great except that it also duplicates primary key information.  We distinguish between cloning and copying as:

This might seem subtle to some and I realize there are ways to change the primary keys, etc. when cloning, but we wanted a true clone process as well.  For instance, we have a case where some work is done on a background thread and we clone the object and pass it to the thread.

More often, however, we have the need to "copy" an object - such as support for copy/cut/paste in a grid.  When doing so, we not only need to duplicate the object with a new primary key (guid in most cases) but also its child objects and so on down the object graph.  This is quite cumbersome to do via the cloning process.  So, our Copy() method on a BO knows how to copy the object, assign a new primary key value and return the copy.  We have the same interface on our collections which know how to instantiate a new collection and iterate through each item, delegating to the item's Copy() method and adding the returned copy into the new collection.  By doing this, the entire object graph easily copies itself.

As you can tell, I am a proponent of building this capability into the framework.  So, hopefully it will move up in priority for the next version.

Thanks!

 

cmclernon replied on Thursday, November 27, 2008

Thanks guys.  Your help is much appreciated.

Regards,

Colm

Copyright (c) Marimer LLC