2,3,n,Tier Architechtures

  • Thread starter Thread starter Kiran
  • Start date Start date
K

Kiran

Hi,

Can some one tell me what are different types of architectures and how are
they related to ASP.Net

And if I create a Web Application for a Login Page, Which tier this
application be.

Thanks
Kiran
 
There are probably as many architectures as there are developers. So the
first question cannot be answered as it depends on the problem and its
constraints.

I have never liked designating tiers with numbers as tier-1 might mean the
UI for one person and database for another, rather I identify them with
their functionality. Well, depending on how your login system is
constructed, it would be hard to tell which "tier" it is in. Might be in
the UI or the middle tier, don't know without looking at your code, and then
it might just be in my opinion.
 
Rather than explaining design patterns, which are useful to a certain
extent, but not always, I would like to explain the basic principles that
underlie most solid architecture. If you can understand these basic
principles, you can architect any application well.

One of the keys to good architecture is loose coupling. What that means is
that Object-Oriented technology enables one to more fully encapsulate
process and data, so that if one is careful, one can design software
components that can be re-used in many applications, not just the current
design.

This is where the concept of tiers comes from. For example, many of your
applications may need to access a database, so it seems logical to
encapsulate basic common database funtionality into a set of classes, or a
"data tier," if you will. Such a tier would manage database connections, and
perform common tasks against a database, dealing only with pure data,
DataTables, DataReaders, etc. As working and manipulating data of various
kinds has virtually nothing to do with the user interface presented to the
end user, it is also logical to encapsulate the business logic that
manipulates the data into a tier that presents no user interface, but only a
programming interface (API). This enables you to unplug that functionality
from the user interface, so that you may expose the same business
funtionality in multiple types of interfaces. For example, we have classes
that parse METAR and TAF aviation weather data, and encapsulate that data
and the functionality for working with it. We have exposed this data in
ASP.Net Server Controls, Web Services, and even a Macromedia SWF that
displays the data visually in a web page.

So, the 3-tier (data, business, interface) model is the most
commonly-mentioned model, but that is really, in effect, a simplification.
As in my previous example, which worked with weather data, not database
data, you may find yourself encapsulating functionality and data into
various compartments. As long as you keep the basic principles of solid
software architecture in mind, you should be able to come up with the most
appropriate architecture for your specific requirements.

Keep in mind the ideas of extensibility and reusability. That is, your app
may now require only one kind of interface. But software evolves. Build it
right and it will be a snap to migrate from ne platform or interface to
another.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.
 
Thanks a lot
Kiran

Kevin Spencer said:
Rather than explaining design patterns, which are useful to a certain
extent, but not always, I would like to explain the basic principles that
underlie most solid architecture. If you can understand these basic
principles, you can architect any application well.

One of the keys to good architecture is loose coupling. What that means is
that Object-Oriented technology enables one to more fully encapsulate
process and data, so that if one is careful, one can design software
components that can be re-used in many applications, not just the current
design.

This is where the concept of tiers comes from. For example, many of your
applications may need to access a database, so it seems logical to
encapsulate basic common database funtionality into a set of classes, or a
"data tier," if you will. Such a tier would manage database connections,
and
perform common tasks against a database, dealing only with pure data,
DataTables, DataReaders, etc. As working and manipulating data of various
kinds has virtually nothing to do with the user interface presented to the
end user, it is also logical to encapsulate the business logic that
manipulates the data into a tier that presents no user interface, but only
a
programming interface (API). This enables you to unplug that functionality
from the user interface, so that you may expose the same business
funtionality in multiple types of interfaces. For example, we have classes
that parse METAR and TAF aviation weather data, and encapsulate that data
and the functionality for working with it. We have exposed this data in
ASP.Net Server Controls, Web Services, and even a Macromedia SWF that
displays the data visually in a web page.

So, the 3-tier (data, business, interface) model is the most
commonly-mentioned model, but that is really, in effect, a simplification.
As in my previous example, which worked with weather data, not database
data, you may find yourself encapsulating functionality and data into
various compartments. As long as you keep the basic principles of solid
software architecture in mind, you should be able to come up with the most
appropriate architecture for your specific requirements.

Keep in mind the ideas of extensibility and reusability. That is, your app
may now require only one kind of interface. But software evolves. Build it
right and it will be a snap to migrate from ne platform or interface to
another.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Neither a follower
nor a lender be.
Click to expand...
 
Back
Top