CommandObject question/suggestion

sune42 posted on Sunday, July 16, 2006

Hi

Is it only possible to get a TRUE/FALSE response back from a CommandObject?

Would it not be practical to have it return any data-type?

Perhaps I am using it wrong, but what I wanted to do is to a "CountOrders" kind of operation and I thought the CommandObject would be a perfect choice in the CSLA framework. Or what object should I use to just execute a simple command that returns a int?

i my case, the GetStatistics() operation would on the server side just do a "Select Count(*) FROM WHERE..." operation and return a int value. 

I think creating a full blown "ReadOnly Root object" would be overkill for a simple operation like this.

Perhaps a NameValueList object would work, but I find that a bit ugly solution.

 

Michael Hildner replied on Sunday, July 16, 2006

Hi sune42,

FWIW, I almost posted about the same question yesterday :) It was my first time needing something like "Select Count(*) From ... Where..." in a project using CSLA.

I copied the example CommandOjbect class from Chapter 7 to get started. That class's public Execute() method returns a boolean. I changed things around so it would return an int and also accept a couple args that I could use in my WHERE clause.

Then in the DataPortal_Execute method I put in the data access code, get the result and store it in my _result field.

Seems to work just fine. Hope I'm not doing anything wrong or pointing you in the wrong direction.

Regards,

Mike

RockfordLhotka replied on Sunday, July 16, 2006

If all you want to do is retrieve a value or a set of values, I'd use a ReadOnlyBase-derived object. That's the purpose of that base class, and it is often lighter-weight than a CommandBase-derived object.

Remember that "weight" is defined by the number and type of instance fields in your class - nothing else matters.

With a ROB you can define exactly the criteria needed to define the request and send only those fields to the server, then the ROB itself contains exactly the fields needed to return the results.

With CommandBase, the criteria and result fields are both defined in the command object - so the empty result fields are serialized to the server, and the now-useless criteria fields are serialized back to the client.

Where CommandBase really shines (imo) is in two areas:

1. When clarity is more important than efficiency. I originally created the commandbase idea to overcome continual questions about how to do what you guys want to do - get a value back by running a database query. It was too high a hurdle for many people to use a ROB to do this, it just didn't "feel right" even though it is the best answer. So CommandBase offers clarity - a base class that is "for running server-side commands".
2. When your use case requires client-side, then server-side, then client-side processing (or two of those three). CommandBase makes it very easy for you to run some client-side code, then move to the server and run some server-side code, then return to the client to run some more client-side code. In this regard, CommandBase is the best and most clear example of true mobile objects to be found in the CSLA .NET framework.

In the book I really only show an example of #1 - through the Exists() commands as discussed in Chapter 8. But the templates, as discussed in Chapter 7, show the model for #2, which is where I think the real power of CommandBase comes into play.

sune42 replied on Monday, July 17, 2006

Thanks for that excellent explaination!

Now I know what to do.

I thought the Command object would be lighter as it has a more specific purpose.

 

Michael Hildner replied on Monday, July 17, 2006

I guess I just assumed that CommandBase would be lighter too. I apreciate the explanation.

Mike