📄 ntier.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
<HEAD>
<META NAME="GENERATOR" Content="Microsoft Visual Studio 7.0">
<TITLE>LLBLGen::About</TITLE>
<link rel="STYLESHEET" type="text/css" href="general.css">
</HEAD>
<BODY>
<br>
<h2>LLBLGen::About n-tier development</h2>
<h4>What's n-tier development?</h4>
<p>
N-tier development is one of the magic buzzwords introduced in the late '90-ies of the previous
century, to describe a method to build applications by 'stacking' layers of logic on top of each other.
Microsoft adapted this model and called it 'Windows DNA', which stands for Windows Distributed interNet
Application Architecture.
</p>
<p>
N-tier applications consist of so called 'tiers' or layers. Each tier has a well defined set of functionality
and acts as a 'black box' for the other tiers in the application. This way, the layer on level B, which lays on
top of layer A and below layer C, uses layer A to do some services and provides services to layer C, the same as
A provides services consumed by layer B. The reasons for the separation of an application in-tiers are:
<ul>
<li><b>Functionality separation</b>. Because each layer has a well defined role in the total application, the
system designers plus developers know where which functionality should be implemented or is located. </li>
<li><b>Functionality reuse</b>. Because each tier provides a service to the layer(s) on top of it, different
layers or tiers or even complete other systems, can use that particular layer to provide some services
for them. This is the basis for the Webservices idea.</li>
<li><b>Functionality abstraction</b>. By defining parts of an application's logic as tiers, you can hide
how that tier provides its services for the rest of the application. This is particular useful when
the application has to grow in functionality. By keeping the interface of the tiers consistent (or at
least backwards compatible) the users of those interfaces, other tiers, will keep working when the
tier's inner logic itself is updated and even totally rewritten.</li>
<li><b>Functionality scalability</b>. Because the tiers are separate units, you can decide to run each tier
in an application on different machines, to keep the system scalable when the load on the application
grows. When an application consists of one big executable, it's hard to chop it up into separate blocks
and run each of them on different servers or even clusters of servers.</li>
<li><b>Functionality maintainability</b>. Because the functionality can be reused, it can also be centralized,
so instead of storing all the logic in one big client and installing that on hundreds of machines, you can now
store all the logic in one tier on a central server and make the clients connect to that tier on that
machine to consume its services. This way a single place of functionality has to be controlled and
maintained. The extra bonus of this is that the databases behind that centralized tier are also shared
among those clients, which means that database-redundancy and the unavoidable inconsistency between
these redundant databases are history. This is the main goal for Webservices.</li>
</ul>
Schematically an n-tier application looks like this:<br>
<center>
<img src="ntiersystem.gif" border="0">
<p class="SmallFontREF" align="center">
<b>A general n-tier application.</b>
</p>
</center>
This picture shows a general application with a couple of layers without any description what each layer does.
It shows clearly that tiers use other tiers to retrieve / store data, or better said: use other tiers to perform
functionality for them. It also shows that multiple tiers can live on the same level, providing different services
using the same tier, clearly illustrating the reuse ability of the n-tier model.
</p>
<p>
<h4>N-tier application types</h4>
Typically, the n-tier model is used to build dynamic webapplications. Most of these applications are build with 3 tiers
or 4 or 5 tiers, where the 3 tier applications are the more 1-client type serving applications and the 4 and 5 tier
applications are the more multi-client type serving applications. The 3 tier application stack consisted of the
following tiers (from top to bottom)
<ul>
<li><b>GUI tier</b>. The layer where the GUI logic of the application is located and generated (if applicable). No
business logic functionality is placed in this tier.</li>
<li><b>Business logic tier</b>. The layer where the logic of the application is placed. This layer is used by the
GUI tier to retrieve data to display / for the user to work with, and to store data in the application's database.
The GUI tier doesn't know how that data is stored, the business logic tier decides that, by calling services
of the data-access tier. As the GUI tier, the business logic tier isn't aware of the concept 'database', it just
uses the data-access tier to store/retrieve/update/remove data.</li>
<li><b>Data-access tier</b>. The tier which handles the direct database activity and provides data-access services
to the business logic tier. No other tier accesses the database directly and the purpose of the data-access tier
is to provide a black-box, database independent interface to the database.</li>
</ul>
The 5 tier application stack is similar to the 3 tier stack but has extra layers to provide extra separation of functionality:
<ul>
<li><b>GUI tier(s)</b>. The layer where the GUI logic of the application is located and generated (if applicable). No
business logic functionality is placed in this tier. This tier can be split up horizontally in separate GUI tiers,
all using the same GUI support tier. Several GUI tiers are necessary when f.e. different type of clients are
provided: a Web-client, a WML client, a WebTV client etc.</li>
<li><b>GUI support tier</b>. To separate GUI-related business logic code from the real business logic code, a
GUI support tier is introduced which has the sole purpose to provide a service layer for several different
GUI tiers, using small, GUI-type specific business logic code. When the business logic layer is very heavy,
which is likely the case in a large webapplication, a GUI support tier is one way to make life easier for
the business logic tier, but also a split up of the business logic tier vertically or horizontally are
options, there are no common rules for this nor limits.</li>
<li><b>Business logic tier</b>. The layer where the logic of the application is placed. This layer is used by the
GUI support tier to retrieve data to display / for the user to work with, and to store data in the application's database.
The GUI tier doesn't know how that data is stored, the business logic tier decides that, by calling services
of the data-access tier. As the GUI tier, the business logic tier isn't aware of the concept 'database', it just
uses the data-access tier to store/retrieve/update/remove data.</li>
<li><b>Business logic support tier</b>. When data required by the business logic tier needs to be pre-formatted or
has to be reworked by basic logic, that functionality is often placed in a business logic support tier, which
sits on top of the data-access tier. Also when data has to be post-formatted before it can be handed out to the
data-access tier, this logic can be placed outside the core business logic layer, to keep that layer clean
from code which deals with the other tiers so it just focusses on the core business rules.</li>
<li><b>Data-access tier</b>. The tier which handles the direct database activity and provides data-access services
to the business logic support tier. No other tier accesses the database directly and the purpose of the data-access tier
is to provide a black-box, database independent interface to the database.</li>
</ul>
Of course this is just a summary of possible n-tier application stacks. Because it's a way of thinking, not a tight set
of 'Thou shall do this'-rules, the developer or the development-team decides how the application will look like, n-tier wise.
Visual Studio.NET Enterprise comes with several n-tier application solutions out of the box, which hold projects for different
tiers.
<h4>N-tier and Microsoft technology</h4>
The different types of typical n-tier applications are implemented using the following Microsoft technology:
<ul>
<li><b>GUI tier(s)</b>. These tiers are mostly implemented using ASP pages with VBScript or JScript. Also
thin clients, build with Visual Basic, Delphi or even VC++ are part of these group. All implementations share
one single technology: COM, which is used to interface with the other layers.
In the .NET world, these tiers are written using ASP.NET and use the variety of
.NET languages to hold the functionality. COM is not used to interface with the other layers, this is replaced
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -