Using CommandBase

dtabako posted on Thursday, April 10, 2008

OK, I've scanned over a lot of threads in this forum about the use of CommandBase and I want to see if I'm clear on some things. It looks like, if I need to run a simple SQL statement (or a SP) on the server I have a few options:

1. Use a command object and pass my criteria data into the Execute() method. Execute() will also, obviously, execute the command.

2. Use a read-only BO and create properties for the criteria data. I'm not entirely sure which method executes the command in this case.

3. Use an editable BO, create properties for the criteria data, and use the Save() method to execute the command.

From what I gathered, I concluded:

1. Using a CommandBase or  a read-only BO object works well if you have few or no criteria and the criteria you do have does not need to be validated in any way.

2. Using an editable BO works well where you have a lot of criteria or where that criteria that needs to be validated.

Have I concluded correctly? If not, where am I off? If I am correct, what would differentiate where I would want to use a command object from where I want to use a read-only object? Also, how exactly would I use a read-only object? Sorry if I'm rehashing tired old questions. I'm pretty new to this framework and I just want to make sure I understand things before I go rattling off dozens of objects.

Thanks, Dennis

sergeyb replied on Thursday, April 10, 2008

dtabako replied on Saturday, April 12, 2008

Thanks for the reply Sergey. For most instances, I'm just kicking off some routine to be processed on the server. Some functions require very few input parameters and some require a lot. For CommandBase and ReadOnly-based objects, the only way I see to set parameters is in the Execute/Factory method respectively. Meaning that if I had to pass, say, 15 input parameters I would have to have 15 parameters to the Execute/Factory method. If I want to avoid that, I could use a BusinessBase object, use properties for the input parameters, and use the Insert or Save method to execute the command. Is there something I'm missing or do i have that right?

Thanks,

Dennis

RockfordLhotka replied on Saturday, April 12, 2008

You are correct, you can use a BusinessBase object to store the 15 values, then have the Command object keep a reference to the BB as a private field so it is available to the DP_Execute() method.

This is a particularly powerful technique for cases where the user needs to enter those 15 values, because you can simply bind the BB object to a UI for the user to do the entry.

One note is that the BB object will probably have no DataPortal_XYZ methods at all, because it has no persistance - and that's fine.

This technique is also really useful for scenarios where you allow the user to enter various criteria values and then use them to populate a read-only list. Just have the criteria object contain the BB so the properties are available to the list object's DataPortal_Fetch() method on the server.

dtabako replied on Monday, April 14, 2008

Thanks Rocky! I was thinking more along the lines of having the BB object store the data and kick off the process - but I like the idea of having it as a backing object for a CommandBase better! As you mentioned I was planning to use a BB for the more complex user entry because of the databinding and validation capabilities. So I think the way I'll go is for functions with more rudimentary input needs - few input items with no validation necessary - I'll go with a straight CommandBase object. And for functions with complex input needs I'll back a CommandBase object with a BusinessBase object that I can use for databinding and validating.

One other thing I'm not quite clear on: In the old app I'm rewriting (an older non-relational, proprietary system) a lot of processing is done in the following manner:

Read a record from a file

Do the necessary processing with it (possibly multiple actions, like posting various totals to various G/L accounts, moving the record from an open order file to an invoice file, etc.)

Go back to step 1 and repeat until you've gone through the whole file

What I'm wondering is, how is the best way to handle something like that? From a workflow perspective it seems to make more sense to handle each entity (not necessarily each record, but perhaps an entire sales order at a time) individually - similar to the current processing model. But from a performance perspective it seems like it would be more efficient to try to write complex SQL to handle things in batches. Are there any guidelines or best practices that can help me out here?

Thanks, Dennis

JoeFallon1 replied on Tuesday, April 15, 2008

I have written a few things like what you are describing.

Here is my approach.

I have a single Winform which is essentially invisible. The app is run on a scheduled basis and checks for the existence of the file. If it finds it, then it imports it into an in memory structure - probably a DataTable. Then the input file is moved to an Archive using yyyymmddOrigName.OrigExt as the new name.

The code in the program then processes the data in the data table by creating a CSLA BO and then populating it with the current row of data. Then I call BO.IsValid and if everything checks out I try to save it in a Try Catch block. If the Save succeeds I continue processing. If the save fails, I log the failure and list of broken rules and increment the count of failures by 1. Then I continue processing. Each success increments the count of successes. At the end I log the number of records that were in the file and the number successfully processed and the number that failed. Obviously corrective action needs to be taken for the failures. (Re-submit a corrected file with only the records that failed previously.)

I have followed this pattern 3-4 times and it works quite well. I especially like the fact that I can re-use the BOs from my Web app for this purpose with no code changes at all. They contain all of the properties and validation code already and I just load them up and check to see if they are valid. I have a few helper methods to extract data from the data table - mostly to deal with the Null value issues.

HTH

Joe

sergeyb replied on Saturday, April 12, 2008