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.
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:
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.
Copyright (c) Marimer LLC