Published: Saturday, December 15, 2001
Where Should Business Logic Go?
By Scott Mitchell
| Read Comments |
|---|
|
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!
|
Introduction
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:
'Query the database and read in the employee's surnames
objRS.Open "SELECT emp_surname FROM tbl_employee", objConn
'Now, display all of the employee's surnames, but if there is
'a hyphen in the surname, split it out into two names
Do While Not objRS.EOF
surname = objRS("emp_surname")
If InStr(1, surname, "-") then
firstPart = split(surname, "-")(0)
secondPart = split(surname, "-")(1)
Response.Write("Name: " & firstPart & " AND " & secondPart)
Else
Response.Write("Name: " & surname)
End If
Response.Write("<br>")
objRS.MoveNext
Loop
|
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 Response.Write(objRS("emp_surname")),
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:
'Query the database and read in the employee's surnames
objRS.Open "SELECT emp_surname FROM tbl_employee", objConn
'Now, display all of the employee's surnames, but if there is
'a hyphen in the surname, split it out into two names
Do While Not objRS.EOF
Response.Write(parseSurname(objRS("emp_surname").Value))
Response.Write("<br>")
objRS.MoveNext
Loop
|
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.
Summary
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.
Happy Programming!
By Scott Mitchell
Reader Comments
The reader comments have been moved.
You can read
them at: http://www.4guysfromrolla.com/webtech/121501-1.comments.shtml
