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*******@devzoo.com> wrote in message
news:eD**************@TK2MSFTNGP11.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