When you think ASP, think...
Recent Articles
All Articles
ASP.NET Articles
Related Web Technologies
User Tips!
Coding Tips

Sample Chapters
JavaScript Tutorials
MSDN Communities Hub
Official Docs
Stump the SQL Guru!
XML Info
Author an Article
Print this page.
Published: Wednesday, December 26, 2001

Where Should Business Logic Go? - Reader Comments

By Scott Mitchell

About a week and a half ago I wrote up an article called Where Should Business Logic Go? When designing a data-driven Web application, there are often certain subtle rules that your output or logic must adhere to. These rules are often referred to as business rules, or business logic. Where should one implement these rules? Ideally COM components should be used, but what if the choice must lie between implementing these rules in an ASP page or in a SQL stored procedure. In that article I argued that business logic, when COM components are out of the question, should be placed in an ASP page, not in a stored procedure. I asked for readers to respond with their views and got some great comments. Thanks all!

- continued -

Where Does the Business Logic Apply?
I think that before we jump right into the answer of where the business logic belongs, we must ask the question, "To what pieces does this business logic apply?" What I mean is this...

If you're building a Web application and that web application accesses data from a database, it is quite possible that two sets of business rules may exist -- those that apply to the specific Web app, and those that apply to the database's content. We should always keep in mind that any given database may be used across multiple web apps and have rules that we want to apply consistently across all apps using the database.

In a perfect world, business rules that apply to database content would applied when the database was modeled and populated, and the database would hold the data in the structure is was required to be used in. Barring that luxury, if you have a rule that applies to data content (regardless of point of consumption) then I'd argue that it makes sense to keep this manipulation with the database, in the form of stored procedures.

More likely, a single Web app may use the same piece data out of the database multiple times and need to use it consistently. If we implement our business logic in the ASP, then everytime that we want to display a name, for example, we'd have to make a call to our local function that handles our special formatting rule. If, instead, our stored procedures handles this logic, then our web app can reuse the stored procedures without any need to be concerned for implementing the logic to format the name.

Now all that being said, I'll argue that the decision of placing business logic ultimately is a subjective one that has to be made based on each app we build. Here are my quick and dirty rules of thumb:

  1. Can you use COM and Does the complexity of your business logic warrant isolation and reuse? Do it!
  2. Do the rules apply to the data, regardless of consuming app? Use standardized stored procs, store logic in the database. Better yet, model your database to incorporate the rule.
  3. Does your web app have rules that are specific to it? Is it truly just a "presentation" business rule? If so, isolate the logic in web app specific functions, just as Scott has suggested.
-- Matt B.

Why COM Isn't Always the Answer
This is a great question, and a good discussion. It's basically "how should I go about writing this type of app?" One point not raised is how much business logic there is. The example had some simple string parsing, but it's never that simple, right? Once there's any amount of complexity or depth or likelihood of errors or whatever in that code, I'd start to be concerned about that server-side cursor that's being left open, and start thinking about doing a rs.GetRows to free up the DB.

This particular example would fly with smart use of rs.GetString in conjunction with a stored-procedure doing the string parsing. The lack of HTML encoding is worrisome, but this can be brought about via GetString by using linefeeds for row delimiters, then HtmlEncode-ing the whole string, then replacing the linefeeds with <br>'s. Unless there's a ton of performance-sensitive or complicated code or you need the code outside of ASP, I wouldn't waste any time getting it to compile in COM.

Show me the performance numbers in an employee listing (or other similar) context to back up the need for COM. I bet the Server.CreateObject and all the late-bound calls will spoil the show. The argument about the ease of changing a COM component in one place is comical: you have to build it, then shut down you site, then un-register the original, copy the new one into place, and register the new one. COM components cannot be lightly patched in the field the way ASP scripts can (seamlessly no less) without a lot of version-control madness: revert to the version of the COMponent's source code that was used for the latest deploy to the site, make the change, build it, deploy it...and hold onto that version of the code, 'cause that's what's out there now...eeck!

There's a reason ASP/VBScript are so frickin' popular, and why xcopy deployment is just about the best thing I've seen out of .NET so far. And yet, .NET will probably having versioning issues of its own, and do you really want a full development environment and *all* your business-logic code on your deployed web server (to reproduce the patch-it-in-the-field ability of ASP).

It should be possible and it may be necessary in a .NET environment to keep ASP.NET and Other.NET things separated like they are now between ASP and COM, just so you have minimal development resources and source code liability on the production servers for patching, and just put developer-built assemblies on the production servers for xcopy deploys.
-- Michael B.

I want to speak to this herd mentality of "things are better in COM". Most web application's business logic isn't that insane - an application developer really needs to balance whether or not the time it takes to instantiate the COM object, use it, and destroy it - is faster or slower than the time it takes to just do it in ASP/VBs. Remarkably, most of the time, it's faster in ASP (especially in the new IIS5/ASP3 combo). Whitepapers and charts will attempt to demonstrate that COM is more scaleable, but in the real world scaleable does NOT equal performance. For the developer sense, it allows the brain to wrap around the little objects of the application (database over here, display layer here, and business logic here...) but in the real world, throwing in the COM in a web application hurts its performance most of the time.
-- Jason G.

Consider Extended Stored Procedures
You could create an extended stored procedure, which actually is a compiled piece of code, and works much like a component. (You can write an extended sp in any language you can write an ActiveX object in.)

No, I don't know if this is going to be faster/slower than COM-objects, but it sure is an option a lot of people don't think of and could come in handy sometime. A lot of hosting providers don't allow COM-objects being registered on their webservers, in that case you could use that same component and add it to SQL Server as an extended SP.
-- Peter

Use Database-Side Logic
MS SQL Server 7 can do string formatting 100-200% faster than ASP 2.0 on an NT 4 platform. I know this from experience, as I had to optimize an internal web app that had the entire development team convinced we needed bigger hardware to continue scaling. My experience with ASP, is entirely 2.0 on an NT 4 machine, so maybe I'm a bit jaded... but ASP is absolutely terrible at doing any string processing, and should be relegated to very simple recordset output to get any scalability out of it.

Another bonus of db side logic, that you don't mention in the article (rightfully so, considering the site) You can better neutralize your Web platform. I generate the all the HTML in the aforementioned project entirely in the stored procedure, making ASP's job quite easy. This also means that it would make PHP/JSP/CF's job quite easy as well. I think there is more of a chance that a company will change web app vendor than db vendor, as the db vendor is much more pricey.
-- Pat W.

ASP.NET [1.x] [2.0] | ASPFAQs.com | Advertise | Feedback | Author an Article