Where ORMs blur the lines between code and data, how do you decide what logic should be a stored procedure, and what should be coded?
- by PhonicUK
Take the following pseudocode:
CreateInvoiceAndCalculate(ItemsAndQuantities, DispatchAddress, User);
And say CreateInvoice does the following:
Create a new entry in an Invoices table belonging to the specified User to be sent to the given DispatchAddress.
Create a new entry in an InvoiceItems table for each of the items in ItemsAndQuantities, storing the Item, the Quantity, and the cost of the item as of now (by looking it up from an Items table)
Calculate the total amount of the invoice (ex shipping and taxes) and store it in the new Invoice row.
At a glace you wouldn't be able to tell if this was a method in my applications code, or a stored procedure in the database that is being exposed as a function by the ORM. And to some extent it doesn't really matter.
Now technically none of this is business logic. You're not making any decisions - just performing a calculation and creating records. However some may argue that because you are performing a calculation that affects the business (the total amount to be invoiced) that this isn't something that should be done in a stored procedure and instead should be in code.
So for this specific example - why would it be more appropriate to do one or the other? And where do you draw the line? Or does it even particular matter as long as it's sufficiently well documented?
