pdsahaystackch06 ntier overview

Chapter 6

Overview of an N-Tier Application

TableofContentsChapter 6 ....................................................................................................................... 6-1

Overview of an N-Tier Application .................................................................................. 6-1

What is N-Tier? .................................................................................................. 6-2

Service Oriented Architecture ............................................................................ 6-2

A Tiered Approach to Development ................................................................... 6-4

Implementation of N-Tier .................................................................................... 6-5Why N-Tier is a Good Choice ................................................................. 6-5Why use Data Access Classes ............................................................... 6-6Advantages of Separating Services ........................................................ 6-7Disadvantages of separating services .................................................... 6-7

Reusable Components ....................................................................................... 6-8The Data Layer Component ................................................................... 6-8The Data Classes (Data Model) ............................................................. 6-9The Business Rules Component ............................................................ 6-9Advantages of a Business Rules Component ...................................... 6-10Disadvantages of a Business Rules Component .................................. 6-10

How to achieve N-Tier ...................................................................................... 6-10Map a Database Object to a Class ....................................................... 6-11Goals of Data Classes .......................................................................... 6-12Benefits of Data Classes ...................................................................... 6-12

Chapter Index ................................................................................................... 6-13


6-2 Haystack Code Generator for .NET Copyright 2010-2011 by PDSA, Inc.

All rights reserved. Reproduction is strictly prohibited.

What is N-Tier? In my travels I meet a lot of programmers who would like to implement an N-Tier architecture, but either dont know how, or say their program does not need a N-Tier architecture. I have found that most business applications should be written at least as a logical N-Tier application if not physical. You will find as you read this chapter that implementing an N-Tier architecture is not too hard. Instead of worrying about a physical implementation of N-Tier (which is what everyone normally thinks has to be done), you would be better to start with a logical separation of services. You will learn a logical implementation of N-Tier in this chapter. You have most likely have heard the term "3-tier architecture". This type of programming has been talked about for at least since 1997 (if not earlier). If you talk with other programmers, most of them do not know how to implement it, or wonder why they should. So first lets define what it is, then talk about why you want to implement it, and finally show an example of an N-Tier application.

Service Oriented Architecture When programmers talk about 3-tier, N-Tier or multi-tier architecture they are talking about breaking up a program into services. A service is typically a component (a class or a set of classes working together) that performs some functionality for an application. Each service can reside on one machine, or can be spread across multiple machines. In the most traditional sense, each machine is considered a "tier", however, I like to think of each service as a tier. Most programmers realize that it may not always be feasible to move these services to other machines, but that it is a great idea to separate each service into a logical component. This then becomes a logical separation of services. Try not to focus on a specific number of tiers or services, just break components into logical services that fit your application, and let that be the deciding factor in how many tiers you end up with.

Service Oriented Architecture

Haystack Code Generator for .NET 6-3 Copyright 2010-2011 by PDSA, Inc. All rights reserved. Reproduction is strictly prohibited.

The typical 3-tier approach dictates that you have a user/display service, a business rule service and a database service. I often find this too limiting, as there are typically many services that work together at the same tier, as well as from one tier to another (see Figure 1).

Figure 1. An N-Tier architecture has many services, some at the same level, and some that work together in a hierarchy.

Below is a table of some of the different services you might find yourself building.

Service Description

UI Service This service is responsible for creating the user interface. For example, Window Forms or ASP.NET is the front-end service. This service will typically interact with many of the other services listed in this table.

Configuration This service is responsible for reading configuration information from either the Web.Config file, or other XML files where you




Service store information.

Exception Handling Service

This service will handle the logging of errors. This service (not described in this book) will take any error and write it to a database, a file, or maybe send an email in order to log the errors that occur in a program.

Business Rule Service

This service will assist you in enforcing data business rules. A good example of this would be that a "start date" must be less than an "end date". These business rules are in the form of code that reside in a method in a class. The front-end service will normally interact with these classes to select, insert, update, delete and validate data. The business rules classes do not select, insert, update or delete, but they inherit from the data access classes in the data access service that do. A business rule class will also model a business process. If you need to update three tables as part of a business process, you will most likely want to wrap up three other business rule classes into a higher level business rule class.

Data Model Service

The Data Model Service is where you define a set of classes that interact with each object in your database. In this model if you have 10 tables in your database, you will create at least one class for each table. This allows you to define all the CRUD (Create/Read/Update/Delete) logic for one table within one class. This one class can then be used anywhere in your application where you need to select from or modify that table. Other objects you will model into classes include stored procedures and views.

Data Layer Service

The Data Layer Service is where you place all your re-useable methods to interact with the database itself. This is where you will wrap up all the calls to ADO.NET.

Database Service This is the database you choose to use such as SQL Server, Oracle, Sybase, Informix or Access.

There are many different types of services that you will most likely need to create for your particular application. The key is to think object-oriented and to always build classes that perform services for other classes.

A Tiered Approach to Development Most programmers are already using a tiered approach but they just don't realize it. Client/Server is comprised of two services (or tiers) a client and a server. I am sure you have been programming these types of applications for years. The term Client/Server is short for two-tier Client/Server. When people think of Client/Server, they typically think of a database application, though there are other examples of Client/Server.

Implementation of N-Tier


The client tier is the application (UI) that the user interacts with. The server tier is the database server that maintains the physical storage and the integrity of the data. The client tier never access the physical data storage directly (such as accessing the physical bytes on disk), but instead communicates with the database server to retrieve or modify the data. The database server takes care of the physical access to the data. N-Tier means that you are adding one or more layers in between the user interaction tier and the database tier as shown in Figure 1.

Implementation of N-Tier To create an N-Tier application you start by designing classes that perform services for you. You compile these classes into class library projects (DLLs). You then use these DLLs from many client applications (Windows Presentation Foundation, Silverlight, Windows Form, ASP.NET, Web Services, WCF Services or any other type of application). You have many different options of how to connect to these components from your front-end application.

Install services on client computer Install services within a Windows Service Use Windows 2008 WAS Use a Web Service

These are but a few of the options you have available. The key is to always design your application as a series of components that talk to each other, and then you have many options. Having options is a good thing!

Why N-Tier is a Good Choice Lets look at the problems with traditional programming where you embed the logic and data access routines on the client side. Many programmers embed business rule and data access logic right in the user interface layer. If you use the same data table in several forms/pages in the same app, you will have to duplicate the code from one form/page to another. If you need to change a rule or data access logic you will have to remember all the places you copied the code to. This can lead to bugs, becomes a maintenance nightmare and is hard to test. In addition, if you wish to change the data access method you use, you almost have to rewrite the whole application, plus distribute new drivers and DLLs to the user.




Of course some people go completely the other way, and try to put as much logic on the database server as possible. This leads to a lot of network traffic just to check business rules and forces the server to do a lot of work to check business rules as well. Then the server has to send a message back to the client application. All this takes time and chews up a lot of resources and makes a lot of round trips around the network. One more disadvantage is that the SQL language is not very robust and thus you may not be able to do very complicated logic. When you create an intermediate tier using a Class Library project (DLL) that will house the business rules and data access logic, there is now only one place to update those rules and data access methods. Also, if this tier resides on the client machine there is no network traffic just to check rules. The user will receive immediate feedback. You also can use a robust language like Visual Basic.NET, C# or any other .NET language to write the logic. You may place these components on a centralized server for ease of updates and distribution. You do need to make sure that the data is protected on the database however, so it is a good idea to keep enough rules on the server to protect the data, in case someone comes in from some other source other than your component.

Why use Data Access Classes Using a set of data model or data access classes does help your application in a variety of ways.

Eliminates SQL from front end UI layer All SQL for one object (table, stored procedure, view) is contained in

one class.

Hides database implementation from other tiers Hides data access method from other tiers Less changes to front end code when column is changed You can get an IntelliSense listing of columns when each column is

mapped to a property

Faster development, less bugs Reusable components that can be used from any other applications Classes in DLLs can be unit tested Can use code generators to create these data classes. Code

generation leads to more bullet proof and tested code. This leads to less bugs and faster development

Implementation of N-Tier


Advantages of Separating Services There are many advantages of separating services into individual components. Lets look at a few of these advantages:

Defines a standard set of properties and methods that can be re-used in multiple clients.

Reduces the amount of code you need to write in the client application. By moving business rule logic to a separate service, it makes it easier to change the front-end from a Windows Form to a Web Form application.

Centralized maintenance of business rules and database services. If you need to modify business rules or the database access method you use, then only the one service needs to be modified, you dont need to change all of the code in your other services.

Potential to distribute the workload across CPUs. If you choose, you may run some of these DLLs under .NET Enterprise Services (COM+) on a separate computer. This can help increase the number of users that can simultaneously access these services.

Disadvantages of separating services Of course there is a downside to implementing components as a service:

There is a slight overhead associated with making all of these function (property and method) calls that can decrease performance. This tends not be a problem however.

There are more projects for you to keep track of. If you create classes for each table in your database, this could

potentially be a lot of classes. In addition if you make properties for each column in each table, this is a lot more code to write as well. (Of course, code generators are available to help generate these properties & standard table access methods such as Haystack Code Generator for .NET (www.CodeHaystack.com).

If you separate the services onto different machines, this cross-process communication can take extra time to perform. Your network performance may suffer as well since traffic for these calls travel across the network. Again, the benefits tend to outweigh this negative.




Reusable Components In most applications you will want to be able to reuse components from a previous project. When you design with classes this becomes much easier. Figure 2 shows a typical N-Tier structure that will give you the best reuse of components.

Figure 2. A typical N-Tier structure.

Let's take a look at each of these layers in the above diagram and describe the usage of each one.

The Data Layer Component The Data Layer component is a separate component that takes care of all of the direct interaction with the database. This layer contains the code that uses ADO.NET to retrieve data and modify data within your database.

Reusable Components


The Data Classes (Data Model) You will typically create one data access class for each table, view or stored procedure within your application. By creating a one-to-one relationship you can have a unique class that houses all of the logic for interacting with that one database object. When you wrap up all the logic for a specific table when you need to reuse that object, you can simply reuse the same class as shown in Figure 3.

Figure 3. Example of a logical Data Class

The logical "Customer class" as shown in Figure 3 contains not only the business class but the data class as well. These two classes together contain the logic to retrieve data, insert, update, and delete data within the Customer table. Since each of the different forms (Form1 and Form2) both need to access the customer table, they each only need to use the Customer class. If each form needs to insert data into the Customer table, they are only using methods of the Customer class to modify the data. If any changes to the business rules or to the data access logic needs to change, it only changes in the one Customer class not within each of the forms.

The Business Rules Component Business Rules are the elements of logic, which control the validity of the data stored in a database for a particular application. Business rules should be placed into a component so they can be used by a number of client applications. In this way you make sure you have a central repository for your business rules. This helps keep the number of places you have to change when a business rule changes to a minimum. The business rule component acts as a go-between for the client and the database server. The business rule server defines and implements any number of interfaces for the client to interact with. Instead of communicating




with the database server directly, the client would communicate with the business rules server, which in turn would communicate with the data layer component to access the data in the database. Does this mean that we no longer need to put any data integrity logic into our database server? Definitely not. The job of the database server is to maintain the integrity of our data no matter what. If a client goes around the business rules component and accesses the database server directly, we need to make sure that they cannot violate the integrity of our data. One of the easiest ways to do this is provide limited access to the database server outside of the business rules component. Utilizing the built in security features of most database servers, you can restrict any or all access to the underlying data except via the business rules component.

Advantages of a Business Rules Component There are several advantages to this approach. First, the business rules component can be written in a more robust programming language. This allows the developer the freedom to use all of the programming constructs and features of the language in implementing complicated business logic. Second, well-defined and documented interfaces can be developed for any number of client applications to communicate with. This can reduce the amount of programming time required to develop client applications that manipulate the data since a good portion of the application logic will be contained within the business rules component. Third, if the business rule logic ever changes, it can be changed in one place. If the interfaces to the business rules component are well defined, any changes should minimally affect the client applications if at all.

Disadvantages of a Business Rules Component In a word: overhead. The more tiers there are in the equation, the more overhead in getting to the data. This can dramatically affect client and server performance if not accounted for in the design of the business rules component. With a little careful planning, you can reduce the amount of overhead that the middle-tier introduces to the equation.

How to achieve N-Tier To create an N-Tier application you will need to perform several steps. First you need to remove as much logic from behind your windows, forms, user

How to achieve N-Tier


controls and web pages as possible. This includes all business rules and data access routines. Place all of this logic into classes and just call the classes from your UI layer. You could also go to the extreme and move all logic out of your UI layer and simply map each window, form, user control or web page to a View Model class and have that view model class interact with the business rule and data access classes. This is a design pattern known as Model View View Model or MVVM.

Map a Database Object to a Class The technique described in this chapter is one that we have been using very successfully since 1995. We map our database objects into classes to ensure that all our data access and business rule handling is all done in one place. This eliminates a ton of code. We also have been using a code generator to generate these classes all this time as well. This has cut down the time to create all of these immensely. Using the approach outlined in this chapter does mean you end up with a lot of classes. For example if you have 50 objects in your database, you will create 50 classes in one or more DLLs. Each individual class is responsible for adding, editing, deleting and retrieving data from one table.

Figure 4. Map one table to a class




The reason we chose this design is to keep things as simple as possible. It is only possible to INSERT, UPDATE or DELETE from one table at a time, so it only makes sense to have one class that performs each of these operations for each table in your application. While it is possible to retrieve data from more than one table at a time (a join), you will not update through a join. In fact, for a join, you will most likely want to build a class that performs that join, but does not perform any modification through that class. Notice the business process that uses both the Customer class and the Sales Class. This is a good example of creating a class that aggregates other classes to get the functionality of each. The advantage you get is you do not repeat any of the data access routines of either class.

Goals of Data Classes Each data or business class you design should strive to accomplish several goals:

Model the base table Add, edit, delete and retrieve data Enforce business rules of the table Expose properties for each column

Benefits of Data Classes The benefits you will get out of meeting these goals will be:

You can have one programmer designing the data / business classes, while another programmer designs the forms/web pages

The UI designer does not need to understand how the data access methods work, or even where the data is coming from

You get a nice division of labor Centralizes all the access to a base table. No duplicate code These classes can be put into very reusable DLLs These components can be used from any language/product

How to achieve N-Tier


Summary In this chapter you gained some insight into the why and how to design a simple N-Tier application. The simple approach to building N-Tier applications makes a lot of sense as it keeps the code easy to create and easy to maintain later.

Chapter Index

BBenefits of Data Classes, 6-12 Business Rule Service, 6-4 Business Rules Component, 6-9, 6-10

Advantages, 6-10 Disadvantages, 6-10

CConfiguration Service, 6-4

DData Classes, 6-9

Benefits, 6-12 Goals, 6-12

Data Layer Component, 6-8 Data Layer Service, 6-4 Data Model, 6-9 Data Model Service, 6-4 Database Service, 6-4

EException Handling Service, 6-4

GGoals of Data Classes, 6-12

MMap a Database Object to a Class, 6-11

NN-Tier, 6-2

Advantages, 6-7 Approaches to development, 6-4 disadvantages, 6-7 How to do it, 6-10 Implemenation, 6-5 What is it?, 6-2

OOverview of N-Tier, 6-2

RReusable Components, 6-8

SService Oriented Architecture, 6-2

UUI Service, 6-3




W Why N-Tier is a Good Choice, 6-5 Why use Data Access Classes, 6-6

pdsahaystackch06 ntier overview

Documents