The N-layers paradigm - is this concept wrong?

Question

I just saw the lecture:

Breaking apart conceptions

He keeps saying that the 3 layers paradigm started because of the problem with connection pooling.

And NOT because of architectural considerations.

Seems like a mind blowing theory.

Can anybody proove or disproove this claim?

Answer 1

This is kind of a hard question to properly answer. The relevant piece of the presentation states that because of the databases not being designed for dozens of connections, there had to be a business layer introduced between the applications and the stored procedures in the database.

I beg to differ. The idea of separating business logic, presentation and storage of state originates much earlier, namely in the 1970 or 1980, and according to Wikipedia was developed at Xerox PARC.

Back then, of course, servers were way more expensive than they are today. However, that still didn't keep them from thinking about maintainability and other aspects of software development, namely testing, debugging and assigning to different teams parts of the development of a full product. It makes a lot of sense to have tightly defined interfaces within an integrated application not for the sake of connection pooling (which is just working around limitations of an ingredient in the entire mixture), but more importantly for keeping the application maintainable and simplifying the development process.

I like the talk though. From practice, I know that blindly subscribing to design patterns can lead you into undesirable situations. You can always overdo everything.

In short though, the multi-tier model (be it on individual servers or just as a development paradigm) is older than the rise of the Internet. It has been kinda commonplace since at least the 1980.