Info

Workstations

Server

Server

Server

Presentation Layer (User Interface)

Middle Layer (Business Logic, Data Access)

Database Layer (Stored Procedures, Data)

Figure 1.9

The three-tier/n-tier architecture takes client-server to the next level by abstracting all the various layers of processing from both the client and the server. It takes some practice to do this correctly. In plain English, what does this mean to you as a programmer? It means you break the application into isolated pieces that call each other as appropriate. You no longer write a single program with intermixed code that creates the user interface, checks the business rules, performs calculations, and updates the database.

When these actions get split into separate functionalities, they can be thought of as separate source code projects. You create the part of the program that deals specifically with showing the graphical user interface in its own project (such as an .EXE created using Visual Basic or Visual Basic.NET). You then create the business logic in its own project that will be compiled into a business logic component (such as a DLL created using Visual Basic or Visual Basic.NET). The business logic component will then be called by the client project to perform any calculations, business rules checks, and so on. The brief summary below states this idea another way.

The Presentation Layer is responsible for:

□ Displaying the user interface

□ Processing user requests

□ Sending user requests to the Middle (Business) Layer for processing

□ Receiving results of the user requests from the Middle (Business) Layer

□ Presenting the results of the requests to the user

The presentation layer can be a Web browser interface (thin client) or a traditional non-Web-based (rich client) user interface. Thin client refers to the fact that very little, if any, compiled code is installed on the client for rendering the user interface. Rich client refers to the fact that a fair amount of compiled code is installed on the machine to make the interface richer to the user. Either way, thin or rich client, the user interface elements are still separated from the other layers.

The Middle (Business) Layer is responsible for:

□ Receiving requests from the Presentation Layer

□ Performing any business logic checks or calculations

□ Interacting with the database

□ Returning the processed results to the Presentation Layer The Data (database) Layer is responsible for:

□ Storing the data

□ Returning data upon request to the Middle Layer

□ Modifying data upon request from the Middle Layer

This three-tier/n-tier architecture allows each processing layer to be built as a set of components (sometimes called objects) that can be called very efficiently from a large number of clients.

In addition to isolating the business logic from the presentation and database layers, it is also very common to further separate any call to the database into its own layer, as shown in the diagram in Figure 1.10.

S-Separation of Logic-N

Presentation Layer

Business Logic

Data Access

Data Store

Using this approach, the summary of the actions performed by each layer is modified as follows: The Presentation Layer is responsible for:

□ Displaying the user interface

□ Processing user requests

□ Sending user requests to the Business Logic Layer for processing

□ Receiving results of the user requests from the Business Logic Layer

□ Presenting the results of the requests to the user

The Business Logic Layer is responsible for:

□ Receiving requests from the Presentation Layer

□ Performing any business logic checks or calculations

□ Returning the processed results to the Presentation Layer

The Data Access Layer is responsible for:

□ Receiving requests from the Business Logic Layer

□ Interacting with the Data (database) Layer

□ Returning the processed results to the Business Logic Layer

The Data (database) Layer is responsible for:

□ Storing the data

□ Returning data upon request to the Data Access Layer

□ Modifying data upon request from the Data Access Layer

Separating Code into Logical Tiers

Although the idea of separating your code into different tiers was just described in the context of designing three-tier enterprise applications, be aware that you can write your Access 2003 VBA applications in multiple logical tiers to make future migrations easier. I will show you why.

For example, if you isolate all code that will touch the database for an add, update, delete, or retrieval of data into its own separate component or module (totally separate from the business logic), it is much easier to change from one database platform to another. Suppose you decide to switch from Access to SQL Server as the database. With the database access code isolated in a single module, you only have to modify the data access components and the database itself. You do not have to touch any of the presentation (user interface) code or the business logic code. Imagine how much easier this is than weeding through dozens of procedures non-related to database access to find what must be modified for the new database platform.

Although you organize the application into separate modules or components, you may not actually run them on separate servers. For example, you may have written a module (such as a VBA module) for all of the business logic and a separate module (such as a VBA module) for handling all data access calls to the database. Although those modules are in separate logical tiers, they may run on the same server (the physical tier). The beauty is that by structuring your Access code properly now, you prepare for future growth if later you decide to migrate to different servers or implementations. Various chapters throughout this book will illustrate these preferred design techniques in detail to make your future modifications and migrations easier.

Now that I have covered how to document your application into a written specification and to determine the appropriate architecture, let's move on to the next phase of the SDLC.

Development Phase

After you have completed the design phase and have a written specification for how your application should function and look, you enter the development phase. Here you begin using Access 2003 and Access 2003 VBA to create your application according to the design specifications you just created. As you are probably already aware, you use Forms in Access to create the user interface. You should use VBA to create the code for the business logic and data access logic. You should use a database such as Access or SQL Server to store the database tables and records.

Because this is a book about VBA, I show you how to write VBA code for the business logic and database access logic using the Visual Basic Editor. Let's take a look at some simple examples in the Visual Basic Editor.

The Visual Basic Editor

As previously mentioned, VBA code is written in Access using the Visual Basic Editor. You can get to the Visual Basic Editor in various ways. One way is to select: Tools C> Macro C> Visual Basic Editor, as shown in Figure 1.11.

You can also select Alt+F11 to open the Visual Basic Editor. Yet another way to get to the Visual Basic Editor is to click Modules from the Objects list in Access, and then select the New option. This is shown in Figure 1.12.

Figure 1.12

Figure 1.13 shows an example of what the Visual Basic Editor looks like.

Notice that the Visual Basic Editor in Figure 1.13 contains a Code window on the right side, a Project window on the upper-left side, and a Properties module on the bottom-left side. The way these windows are arranged can be customized to suit your preferences. Additional windows can also be displayed by using the View menu.

What you see in the Visual Basic Editor depends on how you got there and what objects are part of the Access database already. The concept of Access objects will be described in detail in Chapter 3. For now, just think of forms, controls, modules, and examples of potential objects that may have VBA code associated with them. In the Project window of Figure 1.13, a new module called Module1 was just inserted. The cursor is flashing in the code window that is associated with Module1. When other objects are present in the Project window, you can navigate through the hierarchy and use the Code window to add or modify code that corresponds to the selected objects.

For example, suppose you have a form in your Access database called frmMain. You have added a command button called cmdText to your frmMain. You can get to the Visual Basic Editor from within

Figure 1.13

frmMain by first selecting the cmdText control and then selecting an event, such as On_Click, as shown in Figure 1.14.

Next, click the button with the ellipses (...) to open the screen shown in Figure 1.15.

On the Choose Builder screen shown in Figure 1.15, select the Code Builder option and then click OK. The Visual Basic Editor is then opened with a new empty procedure for the cmdTest_click event in the Code window, as shown in Figure 1.16.

Notice how you now see the frmMain Form in the Project window in the upper left-hand side of the screen as well. Let's look at a few examples of how you can add code to the Code window using the cmdTest_click event as an example. If you begin typing a command in the code window, such as the msgbox command, a tooltip appears (where available and appropriate) to provide you with details on the syntax required for that command. An example of this is displayed in Figure 1.17.

Another helpful feature of the Visual Basic Editor helps you complete a particular command by displaying a list of available options. An example of this feature is shown in Figure 1.18.

Notice in Figure 1.18 how the docmd command has been entered followed by a period. The moment you type the period, the available options for docmd are displayed. You can then select one of the available options from the list. In the development phase, you use the Visual Basic Editor to write the code to implement the business logic and database logic for your forms.

Figure 1.14

Macro or function that runs when control is clicked

Figure 1.14

Figure 1.16

<53 Microsoft Visual Basic - BegAccess2003VBA - [Form frmMain (Code))

• !fc>

Elle £dlt View Insert Debug Run Tools Addlns Window Help rvpe»quesSonfw"ctp

. B X

a

I ä - ifl ft 1 -n J ; ^ Li) 6, Co! 8 -

jcmdTest [cFtek

zl

Cpcion Compare Database

Private Siib crodTeat-^CixcIcO

MsgBoxiPrompt, [Buttons As VbMsgBoxStyle = vbOKOnlyJ, I77£fe]. [HetpRle], [CoßtexiJ} As VbMsgBoxResult

£nd Sub

y

i

Figure 1.18

After you have developed all or part of your code, you enter the testing phase.

Testing Phase

In the testing phase, you test the application to ensure it works. Testing is an iterative process. For example, unit testing should be performed as different parts of the application are completed. Also, system tests at the end should be completed to ensure that various parts of the system work correctly together. To test the code you create using the Visual Basic Editor, you can use various techniques, as I describe in the following sections.

Running and Debugging Code in the Visual Basic Editor

The Visual Basic Editor allows you to debug, compile, and run your VBA code. The steps involved in running and debugging your application are illustrated in detail in Chapter 2 in the Debugging section. However, to give you just a few examples of how the testing phase works, look at some of the types of techniques you can use to test your code.

As shown in Figure 1.19, breakpoints can be added to particular lines of code so that execution stops when that line is reached. Breakpoints can be set at various places in your code so you can stop on selected lines of code to analyze various aspects of the application at that particular time.

■j?] Microsoft Visual Basic - BegAccess20Q3VBA [design] ■ [Form_frmHain (Code)]

- SIS

Eile Edit View Insert Debug Run Jools Add-lns Window Help

Type a question for help ▼ _ i? X

a

Uli i

Ä ja i -J >

|j^jUJs t' Ln 5, Col 13

¡6

JcmdTest

J

| Click

Option Cornpa]

:e Database

*

Private Sub cmdTest Click()

Dim txtTest As String

End Sub

_iT

Immediate X

Locals

it

Watches

xj

cReady■

Expression | Value

| ~ype | Context *

Expression lvalue j Type

<

Figure 1.19

Notice how in Figure 1.19 and Figure 1.20, the screen includes Immediate, Locals, and Watches windows. The Immediate window allows you to obtain information at a particular point in time, such as when a breakpoint is encountered. In the example in Figure 1.20, the current value of the txtTest variable was retrieved using the Immediate window by typing ? txtTest in the window just after running the line of code that set the value of the variable. In the Locals window, you can see that all variables of the current procedure are displayed, which in this example is the txtTest variable. The Watches window is currently empty but allows you to establish rules for watching certain activities as they occur.

As mentioned previously, these testing techniques and several others will be covered in the Debugging Section of Chapter 2. For now, just be aware that you write your VBA code in the Visual Basic Editor according to your design specifications. The Editor has various features that allow you to run, test, and fix your VBA code for the application. You will be using the Visual Basic Editor throughout the entire book, so you will become very familiar with how it works.

Implementation Phase

After you complete the testing phase and have corrected your application, you enter the implementation phase. In this phase, you distribute the application to the end users. In Access, there are various ways to distribute your application, as I discuss in detail in Chapter 10.

Figure 1.20

After you implement the application, each of the phases discussed herein can be repeated as necessary, such as when new features are added.

Summary

Access 2003 VBA is an example of a programming language that can be used to extend your Access applications. As part of developing Access and other applications, you should follow a development methodology such as the Systems Development Life Cycle to facilitate the development process and reduce the amount of rework needed later.

The SDLC includes various phases, including the requirements gathering, design, development, testing, and implementation phases. In the requirements gathering phase, you determine the list of features that the application must include. In the design phase, you document the application on paper so you know how to code it. Some examples of how you can document your design include using Use Cases, Activity Diagrams, and Screen Prototypes. As part of the design phase, you determine whether to use the standalone or client-server application architecture. In the development phase, you use Access to create your forms, and VBA from the Visual Basic Editor to create the business logic and data access code for your forms. In the testing phase, you use the Visual Basic Editor to test and fix your application. In the implementation phase, you prepare and distribute your application to end users.

With this chapter under your belt, you now move on to Chapter 2, where you learn the basics of writing and testing VBA code using the Visual Basic Editor.

Exercises

1. What are the phases of the Systems Development Life Cycle (SDLC) and the purposes of each phase?

2. What are some examples of the ways you can document your design in the design phase of the SDLC?

3. What is the difference between a standalone application and a client-server application?

4. What are the advantages of separating your code into logical tiers in your Access applications?

0 0

Post a comment