Design – API in the 3-tier architecture

I would definitely put AccessControl on the DAL.

Here's some reasons I can think of:

• Quite often you will have multiple UI forms for the same data, and you would have to code your AccessControls into all of them. Making updates would also be more time consuming and prone to errors as you'd have to remember to update every form that references that data when a change occurs.

• If you decide to make another version of the application in another framework, such as a web version of a desktop app, you would have to re-create all your AccessControls for the new UI. If the AccessControls were in the DAL, you just need to hookup to your DAL and create your UI.

• Without AccessControls on the DAL you open up a bunch of security holes. If someone can bypass your UI they have access to all your data

The definition of 3-tier architecture is a special case of the n-tier architecture. In an n-tier architecture, there are n components and each one only interacts with the component immediately "above" and "below" it. A three-tier architecture has three such components.

Typically, a three-tier architecture consists of a user interaction layer, the business rules layer, and data services (including databases) layer. The user interaction layer only issues requests to the business rules layer, which retrieves data from the various data services, processes it, and then returns it to the user through the user interaction layer.

The n-tier architecture is an example of an architectural pattern (or architectural style). It simply defines some constraints on the architecture of the system. By itself, it is not a complete view of the architecture of the system. Although I'm sure that there are systems that implement something like a three-tier architecture, it is just a pattern that's meant to set up a discussion for additional design and implementation of a system.