VB beginner’s guide to n-tiered programming (part 1 of 4)

This post will introduce n-tiered programming for desktop applications and then end with how to setup a Visual Studio Solution for this type of development. n-tiered programming can make your code much more organized and easier to maintain and debug. The premise is to split out your code into various layers with its own focus. Like good web development which splits out functionality (javascript), presentation (css), and structure (content/html) – good application development can involve splitting out your code between different layers.

My solutions are split out to the following layers:
- Data Access Layer
- Business Logic Layer
- Presentation Layer

I usually use this 3-tiered architecture. Other tiering paradigms and numberings exist, but this is the one I tend to use. Specific conventions may differ among different programmers, but most will agree on the basic tenets.

Each layer should have its specified scope and no other layer should encroach upon it. The layers tend to bubble up data and drill down user interactions. In other words, the Data Access Layer will fetch data, feed it to the Business Logic Layer. The Business Logic layer will process this information and send it to the Presentation Layer. The Presentation Layer will graphically convey this information to the user. Inversely, the Presentation Layer will capture user interactions and abstracts the users’ intentions to the Business Logic Layer. The Business Logic layer will abstract this to some business logic-centric action and send it to the Data Access Layer. Data Access Layer makes the necessary changes/requests to the database.

The Data Access Layer handles all calls to the database. No other layer is allowed to interact directly with the database. Except in very special cases, no other layer should contain any SQL (select, update, insert, stored procedure calls, etc) at all. Anything database-related is the Data Access Layer’s property; don’t let other layers creep into it. It should not contain complex logic. Even the simplest processing of returned data (i.e. – checking for nulls) should be avoided here. Under no circumstances should anything related to Windows Forms be in this layer.

The Business Logic Layer handles all the business rules and logic. If you are creating an application for a toy store – and a customer can only buy 10 Lego sets; the Business Logic Layer should enforce this. It can receive information from the Data Access Layer (almost always as datasets, or objects from scalar database calls), but not directly access the database. It can check for NULLs and process the information from the Data Access Layer. It also cannot directly interact with any sort of Windows Form Object. But it can receive indirect commands from the Presentation Layer and feed them back to the Data Access Layer.

The Presentation Layer handles all Windows Forms coding. It handles form events and the appearance of the interface. Anything UI related can be placed here. It does not contain any complex processing not related to user interface interactions. It does not make any direct calls to the database.

What does this mean for my Visual Studio Solution?
In my solution, I usually create a solution folder for each of these layers. You can right-click the solution, go to “Add” and then choose “Solution Folder” Inside these solutions sit various VS Projects for each layer. I tend to name the folders “Data”, “Logic”, and “Presentation” – so that Visual Studio will sort the folders in that order. The order corresponds to the “proximity” or closeness to the actual user. The Presentation layer is at one end because it is directly what the user sees and interacts with. The Data Access layer at the other, because it is furthest in interaction to most users.

I further detail the practical coding aspects of each layer in my following posts.
VB Beginner’s Guide to the Data Access Layer
VB Beginner’s Guide to the Logic Layer
Wrapping Up n-Tiered Programming (Linking All Your Projects together)