Separating the User Interface from the Business Logic
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This article is the third in a series of articles I have written for InformIT that describe how to develop scriptless, scalable Web applications using Visual Basic 6. In this article, I'll enhance the sample application to use a three-tier architecture by splitting the application's logic into two COM, ActiveX DLL components: one to handle the Web user interface and another to handle the business and data-handling logic.
To get the most from this article, you should have already read my previous articles in this series; and you should be familiar with using ASP, VBScript, and either Microsoft Internet Information Server (IIS) or Microsoft Personal Web Server (PWS) to develop and debug applications for the Web. I should also add my standard disclaimer that in order to keep the sample application simple to understand, it isn't as robust as a production application should be and I make notes where it is a good idea to include additional logic. Finally, the code for the sample application is too lengthy to be completely included in this article. Instead, you can download a zip file containing all the code necessary to run the sample application here.
Three-Tier Architectures
The design goal of three-tier (a.k.a. multitier, n-tier) architectures is to separate an application's logic into three separate tiers:
The client tier (a.k.a. user interface tier, user services) is responsible for the presentation of data and interacting with the user. These days, the client tier is probably an HTML-based Web application, a Windows graphical user interface (GUI), or both.
The middle tier (a.k.a. business logic, business services) provides the logic that contains the business rules, and also contains the code to interface with the data tier.
The data-tier (a.k.a. data services) is responsible for data storage and is most often implemented using a relational database management system (RDBMS) such as SQL Server.
The advantages of the three-tier architecture are widely documented and include the following:
Changing the way the data is stored won't affect the user interface code.
It can decrease duplicate development effort by allowing the business logic to be shared among various types of user interfaces such as a Windows GUI, an HTML-based Web UI, or a PDA interface.
It has the potential to decrease application development calendar time by more easily allowing one developer or team of developers to focus on the code for the user interface, and allowing another developer or team of developers to focus on the business processing logic for the application.
It gives you more flexibility with how your servers are configured by allowing you to run code where it is most efficient. For small businesses, the application components might run all on one server. For an application that needs to scale, its components can be spread across many servers. For example, one could be running IIS, a second running your Web UI code, a third running the business logic, and a forth running the RDBMS.
For applications developed with Visual Basic 6, three-tier architectures are most commonly developed by encapsulating the middle-tier business logic in a COM (a.k.a. ActiveX DLL) component. This component can be shared with an HTML-based Web UI component running under IIS and ASP as I've been doing in this series of articles, and with an executable providing a Windows GUI.
When I first started developing n-tier applications, I searched around for a snappy term and associated acronym for the components that contain the business logic of an application. The term "business objects" seemed good, but the acronym "BO" didn't. I found that most of the time these types of components contained at least as much logic for reading and writing data to and from the DBMS as they did business rules, so I started to name them "data handling objects," or "DHOs" for short. So when you read DHO in this rest of this article, remember that I'm talking about a middle-tier, business logic component.
The previous version of the sample application allows the user to search the Publishers table found in the Biblio.mdb database. In this new version, the application logic will be split into two components. I'll keep the existing Web UI component, but move the logic that handles the reading and writing of the Publishers table information to a new PublishersDHO component. To keep things interesting, I'll also enhance the application so it allows the user to modify Publisher records.