The 2-Tier Web Problem

 

Jason Masterman
DevelopMentor

September 1999

Summary: This article discusses how to solve the problem of mixing data access code and presentation layer code when building Web applications. It describes how to use Visual Basic 6.0 WebClasses and components with eXtensible Markup Language (XML) to build a Web application framework. (7 printed pages)

Download sample code Download the sample code for this article.

Two-Tier Web Applications

Developing well-designed, maintainable Web applications requires a tremendous amount of planning and effort. Many Web development tools available today promote rapid development of poorly designed, spaghetti code applications. It's not to say that the tools are bad, or that the tools are the problem. Rather, the tools have made the task so easy that my grandmother could build a Web application with very little effort or training. The problem with this is that it is also easy to build Web applications that don't separate the presentation tier from the data tier. In essence, it is too easy to build a two-tier Web application that won't scale. Active Server Pages (ASP) applications are no exception to this exploding problem. Consider the following code snippet from an ASP page:


<%@ Language=VBScript %>
<HTML><HEAD></HEAD><BODY>
<%	
	dim sConn,sText,sTHead,sTClose
	dim oConn, oRS
	sConn = "Provider=sqloledb;Server=(local);Database=Pubs;UID=sa;Pwd="
	set oConn = server.CreateObject("ADODB.Connection")
	
	oConn.Open sConn
	
	set ors = Server.CreateObject("ADODB.Recordset")
	oRS.Open "Select au_lname from authors",oConn
	
	sTHead = "<Table>"
	do until oRS.EOF
		sText = sText & "<TR><TD>>" & oRS("au_lname") & "</TD></TR>"
		oRS.MoveNext
	loop
	sTClose = "</Table>"
	
	Response.Write sTHead & sText & sTClose
%>
</BODY></HTML>

This is not a very complex page and it contains something that many ASP programmers are guilty of. Can you see it? Not only is it an ugly page, but it also has mixed presentation layer code with data access code. This is a very common piece of code found in many ASP applications today and it should be avoided. This coding style really creates a two-tier application.

The browser may have requested the page, but the browser will do nothing more than function as a rendering engine for the Hypertext Markup Language (HTML) that is sent back. The ASP page, on the other hand, is really acting as the client tier and middle tier. Since the ASP code opens a connection to the database, submits the query to the back end, and determines the presentation and view to send back to the browser, we are back to our old ways of creating a two-tier application in a three-tier world.

We need a better way to approach building our applications. But before we get into some alternatives, what are all the problems with the above approach? In the first place, we know that mixing presentation layer code with data access code is fundamentally a bad design choice. Doing this limits scalability and makes it harder to separate tasks between programmers (who write the data access code) and designers. Second, the type of programmer that can maintain this code would need skills in both user interface and graphics stuff, which is usually handled by people more graphically inclined. This programmer would also need skills as a database programmer familiar with SQL, objects, ActiveX Data Objects (ADO), and VBScript. Clearly there are two different skill sets required. Granted, some people possess both, but the majority of people I have worked with all agree—graphics people typically are not programmers and vice versa.

Using Middle-Tier Components

So, what are the alternatives? Components running in the middle tier are one alternative. Using this approach, we can move the data access code and business logic out of our ASP page and into a component that is invoked from the ASP page. This is the more widely accepted approach today. Once we move our data access code into components separate from the ASP code, we have some choices about which technology we can use. We can do it the manual way, using Visual Basic components that run in the Microsoft® Transaction Server environment and leverage context information provided by Microsoft Transaction Server and ASP. Or we can take a similar approach, one that still leverages context and ASP but doesn't necessarily require Microsoft Transaction Server.

The first approach involves making a reference to the Microsoft Transaction Server and ASP-type libraries in your component, and then utilizing the available context information to get what you need when the component is called from an ASP page. The second approach leverages a framework known as WebClasses that became available in Visual Basic 6.0. One of the major goals of both techniques is to separate data access code from presentation layer code. This helps solve the problem of mixing too much stuff in your ASP page.

Okay then, how do we do it? To leverage my first example, look at the following ASP code:


<%@ Language=VBScript %>
<HTML><HEAD></HEAD>
<BODY>
<%
	dim sTable
	dim oRef
	set oRef = Server.CreateObject("BusObj.CFoo")
	oRef.ShowAuthors
%>
</BODY></HTML>

This is a very small piece of code and it accomplishes the same task as the original piece of ASP code listed in this article. All we are doing in this ASP code is calling a business object that is running in Microsoft Transaction Server. That component "knows" how to access the database and display the authors in table format. The code in that component is as follows:


Option Explicit

Public Sub ShowAuthors()
  Dim ctx As ObjectContext
  Dim rsp As Response
  Dim sConn$, sText$, sTHead$, sTClose$
  Dim oConn As ADODB.Connection
  Dim oRS As ADODB.Recordset
    
  Set ctx = GetObjectContext
  Set rsp = ctx.Item("Response")
    
  sConn = "Provider=sqloledb;Server=(local);Database=Pubs;UID=sa;Pwd="
  Set oConn = New ADODB.Connection
    
  oConn.Open sConn
  
  Set oRS = New ADODB.Recordset
  
  oRS.Open "Select au_lname from authors", oConn
  
  sTHead = "<Table>"
  Do Until oRS.EOF
    sText = sText & "<TR><TD>" & oRS("au_lname") & "</TD></TR>"
    oRS.MoveNext
  Loop
  sTClose = "</Table>"
  
  rsp.Write sTHead & sText & sTClose

End Sub

Note that this code looks very similar to the original ASP code. It does all the data access, but it also has some more interesting pieces to it—mainly, the references to ObjectContext and the Response object. The Microsoft Transaction Server run time and the ASP run time provide us with these objects. If you have done any ASP programming, you should be familiar with the Response object and its methods that allow you to write information out to the browser. The ObjectContext in Microsoft Transaction Server gives you, the developer, a way of reaching up into the available context information provided by ASP, and snatching out the Response object. This contextual information is passed along to you when your object is created from the ASP code.

We now have solved the problem of the ASP code acting as the presentation layer and the data access layer. However, there is also a critical flaw with this piece of code—the presentation layer stuff is in it! We managed to do it again—we mixed data access and presentation layer stuff in the same tier. In essence, we have moved the problem. Once our Business object is compiled, we will still have some presentation details locked into our binary that will be impossible to change without recompiling the source.

So, what are all the problems we need to solve? First, we must move the data access code into a business layer set of objects. We have accomplished this much by using the Business object. Second, we need to keep the presentation layer out of any components that perform data access, which means the presentation stuff really belongs back in the ASP code or in some type of template that can be easily modified without having to recompile.

At this point you might think the answer is to have the component return an ADO Recordset to the ASP. The ASP would call the component and then build HTML from the Recordset returned by the component. This does separate the presentation layer from the data access code, but it still requires the Web page designer to know how to call the component. What we are looking for is a solution that separates Web designers from programmers.

Using WebClasses and XML

So, here comes the WebClass. A WebClass provides the framework for our Web application. The WebClass object provides the ASP page that our clients request. The ASP in turn serves as the entry point into our WebClass and the Business object. From within the WebClass, we call our Business component to do the data access work. When our Business object is done finding the authors, the data is given to an HTML template for display. The HTML template is responsible for all details relating to how to display the data given from the database. For all of this to work, and to keep from having to place table generation code in the WebClass, the Business object saves the results into an XML format that the HTML template can render as necessary. For more information on building WebClasses see The Web Class Developer's Primer. .

Let's look at the code in the ASP file generated by the WebClass:



Let's look at the code in the ASP file generated by the WebClass:
<%
Server.ScriptTimeout=600
Response.Buffer=True
Response.Expires=0
If (VarType(Application("~WC~WebClassManager")) = 0) Then
	Application.Lock
	If (VarType(Application("~WC~WebClassManager")) = 0) Then
		Set Application("~WC~WebClassManager") =
		_Server.CreateObject("WebClassRuntime.WebClassManager")
	End If
	Application.UnLock
End If
Application("~WC~WebClassManager").ProcessNoStateWebClass "Project1.WebClass1", _
		Server, _
		Application, _
		Session, _
		Request, _
		Response
%>

The first interesting piece of code is the line that creates the WebClassRuntime.WebClassManager object and stores it in the application variable ~WC~WebClassManager:


Set Application("~WC~WebClassManager") =
_Server.CreateObject("WebClassRuntime.WebClassManager")

The WebClassManager lives in a file called Mswcrun.dll. When we create our Internet Information Server (IIS) Application, Visual Basic sets a reference to this library for our application. If you go to the object browser in Visual Basic, you can see the WebClassManager class listed under the WebClassLibrary. Note that you cannot see the WebClassManager class unless you select the Show Hidden Members option in the object browser. The Mswcrun.dll is the run time for our WebClass. The run time serves as an entry point into our WebClass and executes code in our WebClass. The WebClass run time stands behind the Web server and the ASP page that calls it. The next interesting piece of code in the ASP file is the call to the ProcessNoStateWebClass method on the WebClassManager. You can see that the parameters passed into the ProcessNoStateWebClass method call include all the ASP objects, as well as the ProgID (Program ID) for your WebClass component (Project1.WebClass1 in this example).

The only real purpose of the ASP page here is to serve as the entry point into our WebClass. Each WebClass gets its own ASP file. This is the only file a client needs to request to access the WebClass. Next, let's look at the code in the WebClass.

Once the WebClass is running, the WebClass simply sets the NextItem property to the HTML template we wish to write out. This is a template that "knows" exactly how to display the XML data we provide for it. The WebClass does nothing to alter the presentation of the template. Rather, the WebClass simply calls the HTML template's WriteTemplate method, which writes the template out to the browser. But before the WriteTemplate method is called, the WebClass simply calls the Business object, creating the XML data for the template to display. The WebClass code is as follows:


Private Sub ShowAuthors_Respond()
  
  Dim obj As BusObj.CFoo
  Set obj = New BusObj.CFoo
  
  obj.ShowAuthorsXML
  
  ShowAuthors.WriteTemplate
End Sub

Private Sub WebClass_Start()
  
  Set NextItem = ShowAuthors
  
End Sub

When the obj.ShowAuthorsXML method is called, the following code executes:


Public Sub ShowAuthorsXML()
  Dim sConn As String
  Dim oConn As ADODB.Connection
  Dim oRS As ADODB.Recordset
      
  sConn = "Provider=sqloledb;Server=(local);Database=Pubs;UID=sa;Pwd="
  Set oConn = New ADODB.Connection
  oConn.Open sConn
  
  Set oRS = New ADODB.Recordset
  oRS.Open "Select au_lname from authors", oConn
 
  oRS.Save sLocation, adPersistXML
End Sub

This code in the Business object creates the Recordset and then saves it in an XML format using the Save method with the adPersistXML format tag. This is a new feature in ADO 2.1. Once this method finishes executing, the WebClass regains control and simply calls ShowAuthors.WriteTemplate. The code below appears in the ShowAuthors template:



<HTML><HEAD><TITLE>2 Tier Problem</TITLE></HEAD><BODY>
<xml id="dsoAuthors" src="authors.xml"></xml>
<table datasrc="#dsoAuthors" datafld="rs:data">
	<TR><TD>
			<table datasrc="#dsoAuthors" datafld="z:row">
			<TR><TD>
				<input type="text" datafld="au_lname">
			</TD></TR>
			</table>
	</TD></TR>
</TABLE>
</BODY>
</HTML>

Summary

At last, we have solved the problem of mixing the data access code with the presentation layer code. We have also provided a framework that allows the HTML template designer the freedom to design a page however he or she sees fit, this includes displaying the data in a table formatted by the template designer as opposed to having one of the other components that retrieved the Resultset create the table.

 

  
  © 1999 Microsoft Corporation. All rights reserved. Terms of Use.