Howdy,
I have a question on when I should use the save methods vs command objects.
We have a medical record. It has several "states" that it may be in.
I hold the state info in a couple of boolean columns in the database.
This state info is pulled into the MedicalRecord object as well as the actual "data" and we use this state info to enable or disable certian buttons in the GUI.
I understand that when the "data" in the MedicalRecord is changed, the object is marked dirty and a save persists this new "data" to the database.
Should I change the "state" info through properties, marking the object dirty, and then save the object or should I use a command object to perform the state change.
An example of a state change is Finalization. When a record is complete, someone will desiginate the record finalized. We change a bit field in the database, is_finialized, from 0 to 1 and insert the users id and the current date.
I can see doing this with both the save or command object. Can you tell me which is the most correct method?
Thank you,
Keith
Both ways are correct.
I would lean towards the one that gives you the most re-use in the most use cases.
e.g. Maybe you change the state in 5 uses cases so if you have a small command object to do this you can use it 5 times. This updates the single field you are interested in.
If you Save the BO then you potentially update each field in the row and that is "overkill" in relation to your needs.
I guess it depends on if you want to update single fields or whole rows.
I would lean toward the command object for the single field updates.
Joe
Joe,
Thank you for your help. I will look at out use cases closer and see which method works best.
Keith
Ajj, Do you have a link to your original question that Rocky answered?
Thank you,
Keith
Ultimately you should consider the way each type of object works.
BusinessBase: A criteria travels to the server and the object comes back. Then when the object is saved, it goes to the server and comes back.
CommandBase: The object starts on the client, goes to the server and comes back.
ReadOnlyBase: A criteria travels to the server and the object comes back.
If you step back from all the other details, these are three models of cross-network commication and you can pick the one that suits your needs best.
For example, the cheapest way to execute an arbitrary command on the server, and to know whether it worked, is to use a ReadOnlyBase-derived object, because a small criteria goes to the server, and a small read-only result object comes back.
But that confuses a lot of people, which is why I created CommandBase. It more clearly defines a way to execute commands on the server, and as long as you limit the number of intance fields in the class it is also quite cheap. The advantage to CommandBase is that it provides for a pattern where you can:
All within the context of a single object. So if you have some work that spans both client and server, then CommandBase is a very good choice.
BusinessBase itself is designed to support the editable root stereotype. Typically the Save() method is called because the user is done working with the object and wants to save it. Save() is not a great choice for small operations that might occur in cases where the user doesn't really want to save the entire object's state.
Thank you. I think you made the case for using the CommandBase for my situation.
Keith
In relation to this discussion...
I just ran into this issue today, and have a question about the Command methods. in the book the example for a command case is an "exists" check, and is implemented as a Shared/Static method (I believe, at least the Exists command I have - which was copied from sample code is).
the question is: Is this a requirement? or can you have a command method that is an instance method? I believe it would be the second option, but just want to make sure.
Thanks,
Mike
It is my recommendation that the actual command be a
static/Shared method.
But you can invoke that method from an instance method.
So with the Exists() command, you can do this today:
if (Project.Exists(_projectId))
but you could change the static method to be private (and have a
different name) and do this:
if (_project.Exists())
Inside the Project class your instance method would be:
public bool Exists()
{
return Project.ProjectExists(_projectId);
}
This is what I’d recommend anyway.
Rocky
From: MikeHamilton
[mailto:cslanet@lhotka.net]
Sent: Wednesday, August 01, 2007 3:37 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Save VS Command
In relation to this discussion...
I just ran into this issue today, and have a question about the Command
methods. in the book the example for a command case is an
"exists" check, and is implemented as a Shared/Static method (I
believe, at least the Exists command I have - which was copied from sample code
is).
the question is: Is this a requirement? or can you have a command
method that is an instance method? I believe it would be the second option, but
just want to make sure.
Thanks,
Mike
Thanks for the fast reply. When you have time if you can explain why you recommend this way?
Mike
Because I like consistency J
The command object should be implemented like every other
business object: with a static/Shared factory method. That way every object in
your business layer works the same way – follows the same structure –
which reduces maintenance costs in the long run.
Rocky
From: MikeHamilton
[mailto:cslanet@lhotka.net]
Sent: Wednesday, August 01, 2007 5:07 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: Save VS Command
Thanks for the fast reply. When you have time if you can explain why you
recommend this way?
Mike
Copyright (c) Marimer LLC