Design question related to updates and inserts.

[Chicagoan2016]

In our team, this question comes up once in a while. Why can't we 'overload' updates/inserts similar to 'Fetch' operation in Csla : )
My explanation is usually along the lines of 'Single responsibility' pattern.

In one of our projects, we have to implement 'restore' operation from history database. We need to show users a collection (of objects) and the user can decide which one to restore.
We have the csla collection and its child object ready (along with business/validation rules).
I implemented this behavior using 'Delete' in our csla objects.
I wonder if there is a better way?

Kind Regards

[rockfordlhotka]

I generally use a command object to undelete or restore something.

Presumably you are showing the user a list of items marked as deleted in history, and they pick one to restore? I'd use a command object to do the actual restore operation on the database.

If the user is also viewing the "live" list of active items, the command object can bring back the restored child when it returns from the server.

Something like this:

using Csla;

var restorePortal = applicationContext.GetRequiredService<IDataPortal<RestoreItem>>();
var restoredItem = await restorePortal.ExecuteAsync(itemId);
// add restoredItem to the parent object


[Serializable]
public class RestoreItem : CommandBase<RestoreItem>
{
    public static readonly PropertyInfo<ItemType> IdProperty = RegisterProperty<ItemType>(nameof(Item));
    public ItemType Item
    {
        get { return ReadProperty(ItemProperty); }
        private set { LoadProperty(ItemProperty, value); }
    }

    [Execute]
    private async Task ExecuteAsync(int itemId, [Inject] IItemDal dal, [Inject] IChildDataPortal<ItemType> childDataPortal)
    {
        // restore item here
        dal.Restore(itemId);
        // get the item from the database
        Item = await childDataPortal.FetchAsync(itemId);
    }
}

[hurcane]

Rocky beat me to the punch. I agree with the idea of a separate command or read-only class to execute the restore operation. Rocky's example uses a simple int criteria parameter to work on one object at a time.

Since you indicated that the UI is a list of items to be restored, I would consider passing in the list as the criteria and the ExecuteAsync method could process the selected items from the list. The list used by the UI is an editable business object, but it does not own the responsibility of making data updates.

I presume the UI has a "Post" or "Save" or "Update" button of some kind. The event handler for that button is where you would bring together the RestoreItem class and parameters. If you use the one-at-a-time model Rocky presented, the looping would be done in the UI. I prefer the "batch" method (loop inside RestoreItem(s)) to save round trips from the client to the server in case the data portal is remote.

[Chicagoan2016]

@hurcane I was wondering about the same. The list the UI uses, is editable business object (a collection) and we allow multiple restores. Hence the question if there is a way the collection itself could implement the 'restore' behavior.
Regards

[hurcane]

Could the collection handle the restore behavior? Yes, if you implement the stereotype for an editable root collection.

But what is the state of the items in the list? Are they new, modified, or deleted? When you start thinking of this, then I think the best question is should the collection handle the restore behavior?

That's up for debate. I would argue for not putting the data updates in the collection class because the collection class defines the parameters for a unit of work -- namely deleting a record from a backup data store and inserting (restoring) the record in a different data store.

The fact that you struggled with how to implement the operation within the collection is a "code smell" that indicates it is not a good idea. Having one set of classes (the list and children) for the criteria and a separate class for the unit of work is cleaner, straightforward to implement, and doesn't look like you're trying to fit a square peg into a round hole.