You could call this 2.5 tier! (now for more than you wanted...)
Strictly speaking a 2 tier app has a client application talking directly to a database.
You can then 'muddy' the water by introducing Stored Procedures and Triggers on the server database - by doing this you shift some of the 'business logic' (a rather wishy-washy term!) to the server. Not stictly a tier, as it can only reside on the same machine as the database, but a logical layer none-the-less.
Now add IIS and ASP to the soup, and you might call this the third tier. As you suspect, it is mearly acting as a remote 'Client' tier. There will probably be some 'validation' logic on the actual client (javascript), as well as the presentation logic (html). Back at IIS the Business Logic (data fetch, insert, update, delete with validation) will reside - yet both are wrapped in the same 'page' of code. Yes, this is a tier - but not quite as distinct as all that, but as it can run on a different machine to the database and client - it is a tier.
Another 'tier' could be 'remote procedures' (DCOM objects, or SOAP/Corba/Tuxedo objects [depending on the OS of the macine that hosts them]). You might call methods of these 'objects' instead of direct calls to the database. They would return or consume result sets, and perform the 'Business Logic'. This layer is the more traditional '3rd Tier'. However, implementing it is painful - both in development time and developer sanity. It becomes most useful when you deal with multiple data sources, or when your web site crawls from excess of ASP.
Basically, the tier description (I believe) identifies how many computers the various lumps of code could run on. So you could add a load balancing layer, a replication layer etc..
Hope this was useful!
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.