Definition of "N-Tier"

[Patrick]

I'm writing a winforms database application in C#. I've come across a lot of
stuff lately about "N-Tier" architecture.

Can anyone give me a simple explanation of N-Tier? The descriptions that
I've found online are chock full of lingo that I simply don't know. I need
the "N-Tier" for Dummies description. Talk to me like I'm in kindergarten.
Of course, I'm particularly interested in how N-Tier relates to creating a
winforms database application in C#.

As far as I understand "tiers", it appears that I'm currently using a 2-tier
architecture. What is N-Tier, and why is that more desirable? What is
"business logic"? Is that where you do your data validation?

(What I really can't wrap my brain around is how you could possibly remove
the data validation from the gui, particularly in a winforms application.)

Thanks!

Patrick

[Erik Frey]

"Patrick" <ne*******@devz oo.com> wrote in message
news:eD******** ******@TK2MSFTN GP11.phx.gbl...

I'm writing a winforms database application in C#. I've come across a lot of stuff lately about "N-Tier" architecture.

Can anyone give me a simple explanation of N-Tier? The descriptions that
I've found online are chock full of lingo that I simply don't know. I need
the "N-Tier" for Dummies description. Talk to me like I'm in kindergarten.
Of course, I'm particularly interested in how N-Tier relates to creating a
winforms database application in C#.

As far as I understand "tiers", it appears that I'm currently using a 2-tier architecture. What is N-Tier, and why is that more desirable? What is
"business logic"? Is that where you do your data validation?

(What I really can't wrap my brain around is how you could possibly remove
the data validation from the gui, particularly in a winforms application.)

Thanks!

Patrick

N-Tier is just fancy-talk for "multiple tiers" (the N may as well stand for
Nerd). For a good overview of designing N-Tier applications, check out the
following:

Application Architecture for .NET: Designing Applications and Services
(Chapter 2)

http://msdn.microsoft.com/library/de...AppArchCh2.asp

Erik

[Bjorn Abelli]

"Patrick" wrote...

What is N-Tier, and why is that more desirable?
It's the concept of creating more or less
*independent* layers of a system.

It comes from when the concept of client/server when the decisions were made
on where the actual "logic" of the application would be; on the client or on
the server, or perhaps separated on several servers?

The technique as such is not confined only to client/servers on a network,
but can also be applied to the architecture of a system on just one single
local machine, but still gives several advantages.

Following thoughts might help you understand the concept:

A) I have written a big application. How much of the
system do I have to change/affect if I only want to
change the User Interface?

B) I have written a big application. How much of the
system do I have to change/affect if I only want to
change how I store the data?

From these two thoughts we can see that there would in most cases be an
advantage to separate it into at least three layers (if you look around a
bit more, you'll see lots of examples with plenty more layers):

1. Presentation logic
2. Business logic
4. Data storage logic
What is "business logic"?
"Think away" how you display your data on the screen, and just see the
presentation layer as a "mediator" between the user and the *actual* logic
in the system. Do it also in the other direction, the data storage logic
only as a mediator of data to and from the database or whatever you use as
the storage of the data...

Simply put, what's left "in the middle" is the "business logic".

If your changes in A) above only affects the presentation logic, you have
sucessfully separated it from the business logic.

If your changes in B) above only affects the data storage logic, you have
sucessfully separated it from the business logic.
Is that where you do your data validation?

Not necessarily, that depends on what you actually mean with "data
validation"

Of course you should make some "data validation" in all three layers.

1. To guarantee that the presentation layer doesn't
send invalid data to the business logic.

2. To guarantee that the business layer works only
with valid data

3. To guarantee that the data layer is able to store
and retrieve data to to be valid in the business logic.

For starters, you can can try to create a winform application, but put as
much logic you can in a separate library. If you're able to use that library
in a web-application (e.g. ASP.NET) as well, *without* any changes, you have
succeded with separating the presentation layer from the rest.

The recollection above is somewhat simplified, but you asked for the
"dummies" version. ;-)

only my 2c.

// Bjorn A

[Bob Grommes]

Hi Patrick,

Thanks for having the courage to ask for a simple explanation. There are
too many acronymns and catch-phrases in this business.

Dividing an application into "tiers" is partly an attempt to increase code
reuse. It's a way of looking at application design from a higher level so
that it takes into account the long-term needs of the organization, not just
a particular application currently under development.

"Business Logic" is code that enforces business rules, such as a rule that
customers are only offered standard discounts of 2, 5 or 10 percent and that
discounts must be approved by a user with certain administrative rights.
The theory is that this rule is true throughout the organization, and so it
should not reside buried in the code of any specific application. Rather,
it should be in some central place and be called by any application that
needs to deal with discounts. So, an Accounts Receivable application and a
Sales Order application, for example, might both use this same business
rule.

So, business logic gets conceptually put in a "business tier" that all
applications share. The idea is to prevent constantly re-inventing the
wheel.

Two-tier apps are also known as client-server apps. They typically consist
of a data tier -- a back end database or a local database engine accessing
shared data on a server -- and the application itself, where everything else
lives.

Three-tier apps attempt to divorce the business logic from the application
and put it in a 3rd, business tier or layer. This might take the form of a
shared DLL used by many apps, or in a more pure form, it might consist of a
server application running in its own process space that responds to remote
calls from any other process. Typically the application talks to the
business layer, and the business layer passes requests to and from the data
layer (the database). Applications thus are written to the API of the
business layer, and only the business layer knows how to talk to the
back-end.

The other reason for adding more tiers is flexibility. If you uncouple
applications from the database itself, then it's easier to swap in different
back-ends, it's easier to support new versions of the back end, etc. The
application just keeps talking to the business layer and doesn't care.

One can have more than three tiers. For example it's fairly common to split
the business tier further into a business and a data access tier. Now you
have:

1) A specific back-end database
2) A data access layer that talks to that database and exposes a standard
API for accessing data
3) A business rules layer that talks to the data access layer
4) The presentation layer -- the UI itself, which talks to the business
rules layer.

Now you have decoupled even more and made it even easier to swap or scale up
different technologies.

Although 4-tier designs are very popular at this time, there are many ways
to design application layers, and so the general idea of splitting code into
layers has just been lumped under the term "n-tier" or "multi-tier" designs.

The downside of multi-layer designs is complexity. Obviously, it takes more
up-front effort (and, frankly, experience) to design a good n-tier
architecture and it's more of an enterprise-level undertaking. Over the
long haul it should pay off, but it is not as simple as just cranking out a
tightly-integrated application.

Another problem is that n-tier architecture is not a perfect metaphor.
There are places where it becomes unclear or impractical to maintain a sharp
division of labor between layers, or where you cannot completely do so. For
example, users expect immediate feedback in the UI if they enter something
incorrectly. A WinForms app would have the luxury of calling the business
layer in real-time to validate a field, but an ASP.NET app has the
fundamental problem that it is VERY disconnected from the server where the
central business layer would live.

So in an ASP.NET app you are forced to replicate a lot of business rules in
client-side JavaScript, and/or introduce a lot of extra post-back traffic
and page reloads in order to validate on the server.

The problem doesn't end there; for example, database stored procedures,
triggers, defaults and rules are often used both as a final data integrity
safety net and as a place to move some data manipulation and querying so
that it can run much faster by avoiding database server round-trips. Often,
such database server code replicates or even supplants logic in one or more
of the other layers.

N-Tier architecture is often touted as a silver bullet, like OO programming.
As Fred Brooks said many years ago, "There Is No Silver Bullet". However,
recognizing the need to centralize logic and improve code reuse as much as
is practicable is a generally Good Thing. If you are building software for
a company and want to take the long-range view, it's the way to go -- but it
will in the short run slow down and complicate your design, and maybe your
implementation at times as well.

Now ... a final note about removing data validation from the GUI. You don't
really remove it, you just don't (if possible) put the code that implements
it in the GUI. You make a call to some external process or library.
Otherwise it works the same. So as I pointed out above, it's actually
relatively EASY to divorce the code from the presentation layer in the case
of a WinForms app. Web apps are the *real* problem because of the
disconnected model of the web.

--Bob
"Patrick" <ne*******@devz oo.com> wrote in message
news:eD******** ******@TK2MSFTN GP11.phx.gbl...

I'm writing a winforms database application in C#. I've come across a lot of stuff lately about "N-Tier" architecture.

Can anyone give me a simple explanation of N-Tier? The descriptions that
I've found online are chock full of lingo that I simply don't know. I need
the "N-Tier" for Dummies description. Talk to me like I'm in kindergarten.
Of course, I'm particularly interested in how N-Tier relates to creating a
winforms database application in C#.

As far as I understand "tiers", it appears that I'm currently using a 2-tier architecture. What is N-Tier, and why is that more desirable? What is
"business logic"? Is that where you do your data validation?

(What I really can't wrap my brain around is how you could possibly remove
the data validation from the gui, particularly in a winforms application.)

Thanks!

Patrick

[Peter Morris [Droopy eyes software]]

Having your database logic in each form and a dedicated db server elsewhere
is typically called Client/Server.

What if another customer wants the form to behave a bit differently? Do you
duplicate the database logic in the first form and make a note "when alter
this code, also update this other form....."? Nope :-)

N-Tier means to separate stuff, for example

1) Database (MSSQL etc)
2) Database logic for your app
3) Forms which use that database logic

You could have 1 on a server, or even 1 and 2 (if you use soap, remoting,
etc).

It's just good practise, you shouldn't mix your gui with your business
logic.
--
Pete
-------
http://www.DroopyEyes.com
Audio compression components, DIB Controls, FastStrings

http://www.HowToDoThings.com
Read or write articles on just about anything