Where Should Business Logic Go?By Scott Mitchell
|At the bottom of this article you'll find some selected reader comments. If you have something to add, be sure to let me know!|
In a recent post to the ASPFriends.com ASPFreeForAll listserv, a poster, Phil W., asked where, exactly, he should place his business logic. In this scenario, Phil's business logic involved some simple string manipulation on Text fields from a SQL Server database. In essence, Phil wondered if it would be better to do it in the ASP page or in a SQL Server stored procedure. Using the ASP way, Phil's ASP page would look like:
In using the stored procedure method, this splitting of the surname into two parts, if needed, would be
accomplished by the stored procedure and returned as one column, as the value of the first part
concatenated with the string " AND " and concatenated with the second part. In such a scenario, the
Do While Not objRS.EOF ... Loop would simply have a
not needing to perform any check for the existence of a hyphen.
In this article, we'll look at my views on this matter, as well as the views of other posters. If you have any comments you'd like to add, please email me them, and I will add some of them to the end of this article.
Keeping it in the ASP Page
In my response to Phil's post, I encouraged Phil to leave the business logic in the ASP page. My reasoning was that the database was designed to do a certain set of tasks very efficiently, and those tasks involve querying and modifying data. Let the database do what it's good at and save the string parsing (something VBScript excel's at) for the ASP page. Another benefit of keeping the logic in the ASP page is that future developers working on this page can clearly see what's happening with regards to the splitting of the surname when a hyphen appears. If this logic were placed within a SQL stored procedure, and the developer just examined the ASP page and the output, they would likely be flabbergasted on why sometimes employee's names were shown normally, and sometimes it read: somePart AND someOtherPart.
The best way to handle this through an ASP page, as poster David P. chimed in, would be to have a
function in the ASP page called
parseSurname, that would take in a string and perform the checks
shown above. With such a function added, the code would change to:
Placing the Logic in the Stored Procedure
Other posters suggested placing the business logic in the stored procedure. Their arguments were that the database can perform the string manipulation faster than the VBScript in the ASP page. I don't know how much weight I give to this claim, personally. Other posters mentioned that if there were a large number of records in the Recordset, and the business logic somehow trimmed these records, it would make more sense for it to occur on the database side so that fewer total records and bytes were sent to the ASP page.
While this last statement rings true, ask yourself how many records are you planning on sending from your database to your ASP page? Ten? Fifty? Hopefully no more than 100. It's not that the ASP page can't handle getting sent 100 or 1,000 records, it's that the end user can't support that many. Have you ever seen a Web page with far too much information on the page to make it readable? Bearing that in mind, ask yourself how many times you're going to be sending a large chunk of data to an ASP page where performing the business logic on the database would save any significant amount of time.
Using a COM Component - the Best Option
Of course the best option is to use a COM component to store your Web application's business logic. (If using a COM component is not an option, though, I personally recommend putting the business logic in the ASP page as opposed to in a stored procedure.) COM components are an ideal place for such logic because it separates the data layer (the database) from the presentation layer (the ASP page/HTML generated from the ASP page). Also, since all of the ASP pages on a Web application can use the same set of COM components, placing your business logic in COM components centralizes such logic, meaning that if you need to change your business rules you only need to update one file - the COM component. Fore more information on splitting out the business logic into a COM component, be sure to read: Using Business Objects in your Web Application.
So where should you place your business logic? I contend that the best place is a COM component, but if that's not available, place it in the ASP page. What do you think? I'd be interested in knowing! Sound off, and I'll append some select responses.
The reader comments have been moved.
You can read them at: http://www.4guysfromrolla.com/webtech/121501-1.comments.shtml