Actually, after digging a little deeper into the differences between n-tier architectures and MVC design patters, what I posted earlier is most likely mislabeled.
A tier-3 design pattern separates the buisness logic, the presentation layer, and the data layer and stacks them in a linear order, where each layer would only be able to communicate with the layers directly above or below it in the line.
This would put the buissnes logic in the middle, able to communicate with both the data layer and the presentation layer, but the latter two would only be able to communicate with the buisnes layer.
Which is pretty much exactly what the code I posted does.
A MVC pattern, on the other hand, defines three separate "modules" of sorts, each responsible for a specific part of the process, but each communicating with the others. (The communication triangle)
- The Model; representing the application data. Receiving updates from the Controller, and providing data to the View.
- The View; presents the application data to the "user". In the case of websites, the HTML output. It would receive data from the Model and present it to the "user". In the case of interactive UIs, the View would also pass on any user interaction to the Controller. (Button clicks and such)
- The Controller; representing the buisness logic. Receives events from the View, interprets them and triggers updates in the Model, which are then reflected by the View.
So, according to my current interpritation of the two design patters, my MVC design example would in fact really be a tier-3 design patten.
(Which should not be confused with a tier-3 architectural pattern, which is apparently something completely different)