You will, no doubt, receive a number of excellent references in this thread.
So, my contribution will be to explain the underlying principles which guide
them all. I have found that understanding the underlying principles of
things makes life much simpler, and aids in the application of the derived
methodolgies, which will vary, as the application of the principles can
manifest itself in various valid ways.
The first principle of N-Tier application development is basically one of
the same prinicples that guide object-oriented programming in general. That
is, by organizing and encapsulating functionality into various independent
"modules," one enhances productivity and avoids many future pitfalls. A
class should have as few external dependencies as possible in order to be as
reusable as possible, so good object-oriented design dictates that classes
should, for the most part, manage themselves. Similarly, for example, the
data layer of a classic 3-tier application should manage itself, and not
perform any business logic with data. It should simply manage raw data from
whatever data sources it is designed to work with.
Loose coupling is another basic principle of N-Tier development. The data
layer of an N-Tier app, for example, should have an API that is not tied to
any specific client, so as to be reusable in any application. It may also
have a back-end which can be configured to work with a variety of data
sources in different ways without much external management. It should
encapsulate its inner workings.
Similarly, the business layer of an N-Tier application should be designed to
manipulate data, to perform the required business logic involved in fetching
data from the data tier, and applying logic to organize and present the data
to the presentation tier. It is the "middle-man" of the application. It is
not cognizant of where the data comes from, nor how it is to be presented to
the user. As far as it knows, it is fetching data from the data tier, and
feeding the data TO the data tier. By not having any presentation logic, it
can be easily re-purposed for a variety of presentation tiers, such as
Windows Forms, Web Services, ASP.Net applications, other business clients,
etc. It should have an API that is not specific to any client.
Finally, the presentation tier encapsulates only user interface logic. It
should not perform any business logic, but rely on the business layer to
organize and manipulate data. The presentation tier should take input from
the user, and use the business layer's API to communicate between the user
and the business layer. In essence, the presentation layer is simply a
communicator. It translates the user's interaction with it into instructions
that are relayed to the business layer. It is "user-friendly," meaning that
the user understands its user interface, and "business friendly" in that it
can speak to the business layer through its API. It is like the old Star
Trek Universal Translator.
By using this combination of the principles of encapsulation and loose
coupling, one will spend less time in the long run in dealing with the
developmnent of the application, identifying and fixing bugs, and the
inevitable changes that occur over the lifetime of an application.
And it is important to remember that the 3-Tier model is basically a rough
idea of these principles. In fact, these 3 tiers are often sub-divided
according to the needs of the developer, and the requirements and
anticipated requirements of the application.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Everybody picks their nose,
But some people are better at hiding it.
