Property Change - Bulk Update

skehiaian posted on Wednesday, July 19, 2006

I've ran into a situation that whenever a specific property gets updated in my root object, I need to recalculate a property for each item in it's child collection.  The problem is that the child collection has about 20000 items which needs to be looped through and have the business logic applied to each item.  This is taking some time to accomplish if I load all 20000 child objects just to update 1 field, update each one whenever the property changes (which freezes the UI for a few seconds), then save the child list back to the database when the root object is saved.  The child objects are not public so they are not even used in the UI.  I have been debating whether this approach is correct or not.  The alternate and much faster way would be to use a stored procedure to update the field in the child records, but that would mean that I would have to put the business logic to recalculate the field in the stored procedure itself.  Any thoughts on this?

Ike Ellis replied on Wednesday, July 19, 2006

I think you do it in the stored procedure.  There's no sense looping through objects when SQL Server can do that so quickly.  I guess I would say, just have the method call the stored procedure, so there it is well-documented where the business logic is.

But then again, I'm brand-new to CSLA and am just now learning the framework, so take whatever I say with a grain of salt.

I love Martin Fowler's quote:

"Question: What is the difference between a methodologist and a terrorist?
Answer: You can negotiate with a terrorist."

I don't know what made me think of that, but I think it applies.

pelinville replied on Wednesday, July 19, 2006

RockfordLhotka replied on Wednesday, July 19, 2006

What they said

Seriously, you have to look at the use cases and the intended purposes behind each part of CSLA .NET and decide what makes sense where. There are six CSLA .NET base classes that work together to support 11 stereotypes - none of which are for batch processing like you describe. The stereotypes are:

1. Editable root object
2. Editable child object
3. Editable root collection
4. Editable child collection
5. Read-only root object
6. Read-only child object
7. Read-only root collection
8. Read-only child collection
9. Name/value list
10. Command execution
11. Process execution

Now you might use "Command execution" to launch your batch process, but none of the CSLA .NET base classes exist for the purpose of implementing such a batch process. This is because the best way (typically) to do a batch process is to do it in the database with a stored procedure.

Failing that, the best approach is typically to apply the Flyweight and Iterator design patterns. Basically load the data into memory in the fastest, most efficient manner possible, then iterate through that data with a Flyweight or Iterator to perform your operation on each row of data, then save the data back in the fastest, most efficient manner possible.

No need for any of the CSLA .NET features here at all - except again for possibly CommandBase so you can transfer the processing to the app server before actually doing the batch process.