Encapsulation of layers in a three-tier software architecture for client-server

Question

The three-tier software architecture for client-server paradigm has three different layers:

1. Presentation layer - A layer that users can access directly, such as UI or Webpage. Also called a client.

2. Application layer - This layer encapsulates the business logic (such as business rules and data validation), domain concept, data access logic and etc. Also called middle layer.

3. Data layer - The external data source to store the application data, such as a database server.

Why is it advantageous to encapsulate the logic of separate layers in separate software modules?

Answer 1

There are a couple of reasons you should encapsulate the logic of separate layers in separate software modules.

1. It forces you to practice Separation of Concerns/SRP.

This horse has been beaten to death, so I will reference other StackOverflow questions. If you truly keep different concerns in different files/modules without too much coupling, you will be a happier developer. You haven't seen hell until you've seen a 30,000 line "God Class" that does everything, and is impossible to add or remove features from, fix bugs in, or refactor.

2. It helps you break up your code into manageable chunks.

Coders have been breaking up code into different modules for some time now because it helps us understand the bigger picture. You typically need the structures and adjectives that modules give you once your system gets beyond a small size, or you need to work with other developers.

3. It can help you distribute your code onto different machines/architectures in the future.

Putting your software into different modules can make it easier to distribute them onto different machines (i.e. distributed computing) in the future. If your modules don't have shared state and aren't overly-coupled, you can move the modules to different machines. It won't do this automatically though, you will still have to deal with the interfaces (rpc/services/etc) and all the fun of distributed computing.

Note: You can easily sidestep all these benefits if you over-couple your modules. Typically you want your minimal module coupling to follow the direction that your data flows (i.e. the presentation layer shouldn't talk to the database).

Answer 2

Great answer, Alex. I would also add:

4. It allows you to build multiple clients

Think of an app like Facebook. There is a Web app, iPhone app, Android app, etc. When an application is separated in this way, developers need only to "re-skin" the app for the iPhone, Android, and any other new client coming out. When the separate iPhone and Web pages are speaking to the same Application layer (via REST for instance), you can be certain that business rules are applied similarly across all platforms.

When you couple view specific logic (compiling HTML) in your application, your new iPhone app may need to hack around this because it doesn't care about HTML. Or if you used business logic (performing multiple calculations on a series of data) in your view layer, your new iPhone app will most likely have to duplicate this code; leading to potential bugs in the future when the calculation needs changing.