Our business app has been using CSLA for a few years now and we do everything as object oriented and re-usable as possible. However, lately i've been running into situations where it seems like i'm using a lot more system resources than I need to.
My main example is a page we have that copies all of the users Permission Authorizations from one of their "reps" to anotherof their "reps". This involves several "Brands" many "Users" for each rep and a ton of authorizations.
So in the past we've used the BrandAuthorizations editable collection, filled it with all of these BrandAuthorization objects (possibly several hundred, even thousands in some rarer cases), created a copy, then inserted this copied objects data into our SQL tables. There was a lot of looping involved with what we were doing and very large, fat objects. We started having some performance issues and time outs on that page when people ran larger jobs.
The solution was to put it all into a single stored procedure. Now i'm passing in three Guid ID parameters and SQL is running a single INSERT command and it's taking a tenth of the time. This is not object oriented and the stored procedure is very specific to this process and isn't particularly re-usable. However, it's way faster and what does our client care about staying true to OO design, they want speed. As the load on our system has increased i've found more and more places where these, I suppose Service Oriented, stored procedures are really speeding up our app.
So i'm wondering how others differentiate between where to stick with OO design and where to drop the objects and just process stuff with simple stored procedures letting SQL do a lot of the work.We still use a ton of objects and will continue to, it's 90% of our business layer and works great. But the more we try to optimize the more we find exceptions and break away. I'm looking for some idea of best practices or ideas about where to split between these two architecture approaches.
I'd say you've hit one of the breaking points squarely on the head. There's no reason to load all the data into memory on your web server just to copy it and re-save it - that kind of processing is what databases are for. If you don't think it's very OO - well, CSLA has a CommandBase object for a reason. ![Smile [:)]](/emoticons/emotion-1.gif)
Essentially what you've done is identify a bulk-processing situation (I wouldn't call it "service oriented") and use the best tool for it. Unless you have to do some significant data transformation that can't be realistically done inside a SP, or if you have to apply a set of business rules to the transformation process, let the database server do its job. I have coded several bulk-processing processes that way. IMHO, any programmer worth his/her salt is going to tell you to do it just like you did.
Aside from the heavy lifting, I also defer to SQL for more automation-type steps that are centered around the database. There have been discussions on the forum about this before, but the example that comes to mind is when you need to update the inventory data to reflect a shipment that your app has processed. Some would argue that loading the appropriate inventory data just to subtract some quantities and send it back to the database is network overkill. Just create an SP to update the inventory, create a CommandBase object to call that SP, and execute that CommandBase object as part of your shipment save routine. If your inventory-updating SP is used in multiple places, then this works just fine. If it's only used in your shipment routine, then drop the CommandBase implementation and just integrate it into the shipment save - but I'd still probably do the work on the database. Again, there's no need to load a bunch of inventory data to your web server just to do some basic math and push it back to the database. You'll also see similar situations suggested when folks have to launch database-centric workflows.
Objects are great - but they aren't great for everything. And re-usability, while a good goal to have, is not nearly as important as it often sounds. Don't get stuck in a dogmatic adherence to objects.
HTH
- Scott
Copyright (c) Marimer LLC