ToBeSaved()
The other day my friend Christoffer Skjoldborg drew my attention to the fact
that not every dirty instance that is sent to a save method in the Service Layer
should actually be saved. The problem is referred objects and the context is
my new architecture.
Let's describe this a bit more. Assume you have a domain model instance for a customer and the customer has a number of orders. In the user interface the user adds a new order for the customer, but doesn't press the save button. Then the user edits the customer instance and saves it, and finally the user decides not to save the new order. Without taking extra care in the application, the new order was probably saved too, even though the user never intended it. The reason is that the order was dirty and was in the object graph that was sent to the Service Layer to be saved when the customer instance was sent. (OK, this was a simple problem that you could easily solve with other solutions, but translate this simple example to a general and advanced case.)
After having discussed this a little, Christoffer and I decided that a good solution might be to add ToBeSaved() as a method to the domain model classes. That method must be called explicitly or else the Persistence Access layer method won't care about the instance. This gives the user back the control of what is ready for being saved.
What we actually get is a three step process for saving, instead of the old two step one. The new one is like this:
Let's describe this a bit more. Assume you have a domain model instance for a customer and the customer has a number of orders. In the user interface the user adds a new order for the customer, but doesn't press the save button. Then the user edits the customer instance and saves it, and finally the user decides not to save the new order. Without taking extra care in the application, the new order was probably saved too, even though the user never intended it. The reason is that the order was dirty and was in the object graph that was sent to the Service Layer to be saved when the customer instance was sent. (OK, this was a simple problem that you could easily solve with other solutions, but translate this simple example to a general and advanced case.)
After having discussed this a little, Christoffer and I decided that a good solution might be to add ToBeSaved() as a method to the domain model classes. That method must be called explicitly or else the Persistence Access layer method won't care about the instance. This gives the user back the control of what is ready for being saved.
What we actually get is a three step process for saving, instead of the old two step one. The new one is like this:
- Property is changed => instance gets implicitly dirty.
- Instance get ToBeSaved() call.
- Instance is sent to save method in Service Layer class.