Way back, before web applications, the idea of 3-tier applications emerged. The idea was quite simple, and predicted a shift of paradigms in applications structure. This was in the era of Client/Server (2-tier) applications, mind you, systems typically built as Windows applications talking to a database server.
The 3-tier model:
The main reasons for predicting this to be the future structure of applications was:
- You need only cheap thin-client machines
- All application logic resides in a separate layer rather than being scattered around the fat client
- It would enable multi-platform clients connectiong to a single application server
The web was in the coming, ant the 3-tier model fitted this quite perfectly. Soon big, processor intensive, memory intensive, expensive desktop PCs would be history. The future would be ideal for cheap thin client machines.
So - what is the problem with this model ?
We'll start with what's the good idea with this model - keeping core business functionally out of the client applications. The old C/S applications were packed with such functionality, talking only to the database server. Efforts were made to help this problem, like creating server side procedures for basic functionality. This effectively resembled having an application middle tier, making a "pseudo-3-tier structure". Also, when talking about web applications, there is no way you can get around an application server.
So, the idea was that all business logic is kept out of the client application. The client itself would be a passive UI holding no information about e.g. whether an order could be placed (if more data is needed, if customer is banned, etc.). Very much simpler, but what about the user experience ? Wouldn't this easily end up being like a primitive web application - you submit and instantly get some red error indicators in return ? Submit again, and hope they're gone ? How do you populate a dropdownlist based on your choice in a previous radio group ? I think you know the answer by now - you cannot. The client application needs to mirror the business model to form a rich UI, giving you the UX you normally would have in the old C/S applications.
I doubt the idea of keeping the business logic away from the UI, because of the answer to this question: - What business rules do not need to manifest in the user interface ? Isn't it so that a good, responsive UI will provide the user with all neccesary help and information to get things right and effectively ?
How to get around these limitations ?
It's quite simple, and every web application programmer of today would know; the client needs to retrieve (meta)data from the logic layer to reflect the business model in the UI. This is not entirely trivial, and if done through components or libraries you would easily find yourself working with something similar to the old databound componets of the RAD age (VB, Delphi). Like I would state in the late 90's: "My middle name is Workaround".
Anyhow, the thin client concept died. For a reason.