Logic in Stored Proc or Business Object?

Logic in Stored Proc or Business Object?

Old forum URL: forums.lhotka.net/forums/t/11580.aspx


TSF posted on Saturday, September 15, 2012

I'd like advice on a specific situation.  My application needs to update a record.  But when that record is updated, I need to modify other records that are linked, in a sense.  For example, a record/object with a value of "1" in a certain field gets updated to "2."  That means the record that already had a value of "2" now needs to be increased to "3," and so on for a few iterations.

One option is for an editable root object to update itself, and also query and update each of the other objects that need to be updated in turn due to the first update.  All the logic would be contained in the BO, and only basic CRUD procs would be needed.  But this seems expensive, because there would be so many calls and lots of data going across the wire.

The other option (which I'm planning on at this point) is to move this logic into a proc, so the proc could do all the updates required - on the database and without any extra data going across the wire.

Or am I not thinking about the design correctly?  Thanks.

skagen00 replied on Saturday, September 15, 2012

fwiw, I would likely do this kind of logic in the sproc myself.

JonnyBee replied on Sunday, September 16, 2012

I'd do it by either a

I would NOT put that logic into the BusinessObject itself.

The choice might vary depending on

Copyright (c) Marimer LLC