Immediate delete of an object vs using a command object

[Chicagoan2016]

We could use a command object if you have to delete a root object (and related data).
We could also use 'immediate delete' instead of a command object.
If we do that, do we still have to set the child objects to 'new' by calling DataPortal.CreateChild (in the delete method of the root object)?

Kind Regards

[StefanOssendorf]

Hi. Sorry I don't understand the question. Maybe you could write an example for your object graph and the goal you want to achieve or avoid.

[michaelcsikos]

I normally don't perform the delete on an editable root object. It's done via a list of read-only objects. After the user confirms, the delete factory method is called passing in the relevant Id. Any children are usually deleted by cascading with SQL, or with some more complicated SQL if there are multiple cascading paths, which confuses SQL Server.

[michaelcsikos]

It's similar to how we delete a file in File Explorer. You see a list, select a file, hit Del and confirm.

You don't expect to have to open a DOCX in Word, mark it for deletion, and then click Save. That's just weird.

[Chicagoan2016]

No, I meant 'immediate delete' of root objects (with child objects)

[hurcane]

We usually implement delete operations to support both techniques via the data portal. An internal method handles the actual delete from the database. A Delete method on the data portal is implemented to call the internal method. The Update method, when it determines the object needs to be deleted, calls the internal method then marks the object as new.

The implementation specifics within the data portal methods will depend on the encapsulation model you use for the data portal. But this allows clients to use whichever technique makes the most sense for the business function. Sometimes, we're working with "info" classes and want to support a delete operation. We'll use the DataPortal.Delete(objectID) technique to directly delete the data. In other scenarios, we'll have an instance of the "edit" class, and then the delete is handled by myObject.Delete() followed by myObject = myObject.Save(), or we might not need the "new" object, so we call Save and set the client variable to null.

Even if we don't need both techniques when we add a new business class to the project, we always code it to support both techniques.

[Chicagoan2016]

We usually implement delete operations to support both techniques via the data portal. An internal method handles the actual delete from the database. A Delete method on the data portal is implemented to call the internal method. The Update method, when it determines the object needs to be deleted, calls the internal method then marks the object as new.

How do you reset root object's properties? We are getting IsNew correctly but even after calling DataPortal.Create in the root object. Root object's properties retain the values.

Thank you

[hurcane]

We don't reset the root object's properties. Keeping the properties allows you, hypothetically, to recreate the object in case we have to handle the "Oops, I didn't mean that!" scenario. If you want to start with a "clean" object, use a DataPortal.Create() call after the object has been saved. I see that as a UI concern, and not a responsibility of the core business object.

[Chicagoan2016]

Here is why I started thinking about it. In an object graph we do 'reset' the child objects from Dataportal_Delete of root object so what if we wanted to reset the root object as well? Couldn't we make it part of Dataportal_Delete of the root object?

[rockfordlhotka]

The CSLA behavior is that when an object is deleted, the state of the object is left alone. The metastate is updated so IsNew is true, because we have reason to believe that the primary key value(s) in the object are not reflected by corresponding values in the database.

If you want a delete that provides a brand new object, as many people have suggested, consider using a command object that does the delete and returns a new object.

[Chicagoan2016]

Thank you everyone, I confused this question with #4240 😊