In a three-tier web architecture, which tier is responsible for business logic, and why should it never be implemented purely in the presentation tier?
- A.Business logic belongs in the database tier (stored procedures and triggers); the presentation tier merely renders pages, and the application tier is a thin proxy that forwards each request to the database with the user's credentials attached, a layout that keeps rules close to the data and makes client-side validation unnecessary for the form fields of the checkout flow
- B.Business logic belongs in the presentation tier (the browser) to cut latency; the server tiers then serve storage and authentication, and each rule runs in JavaScript where changes are shipped with each release of the front-end application, a model that lets teams update rules without touching the database or the application servers
- C.Business logic belongs in the application/middle tier; the presentation tier (browser/client) is entirely attacker-controlled - any logic placed there can be bypassed, modified, or disabled. A user can disable JavaScript, use browser DevTools, or intercept HTTP traffic to skip client-side validation and business rules entirely