It seems to me that, in that original design, the JSP servlet acting as a Controller was a multi-use object that would serve many requests?
To me, one of the weirdest things about Rails-style MVC is that a controller is reinstantiated for every request and then promptly thrown away. I'm used to thinking of controllers in desktop apps as rarely-destroyed objects which do a lot of communication with each other.
The Rails-style controller could just be called "RequestHandler" or something like that, IMO.
It's actually kind of funny when you tell Java/C++ guys about how each time PHP receives a request, fires everything up from scratch, does the work, and then throws it all away. A fresh start each time.
What's even funnier is that in javaland they took advantage of long-lived objects by having deep and broad class hierarchies, with all code in instantiated objects ... which the PHP community emulated in their frameworks, instantiating a bazillion objects on every request just to throw them away immediately. IMHO it's no surprise that in the techempower benchmarks raw php is orders of magnitude faster than a symfony implementation.
Generally, Servlets were multi-use objects that would serve many requests simultaneously. Except that in the early days, you could tag a Servlet as a SingleThreadModel which would tell the container to only allow one request at a time to be served by an instance of the Servlet. Lots of requests led to lots of instantiations.
This was seen as a terrible practice, whose sole benefit was to allow lazy programmers to have state variables in their controllers, and was promptly deprecated. Only to have Rails and other similar frameworks basically pick it up!
Comments
Interesting, thanks.
It seems to me that, in that original design, the JSP servlet acting as a Controller was a multi-use object that would serve many requests?
To me, one of the weirdest things about Rails-style MVC is that a controller is reinstantiated for every request and then promptly thrown away. I'm used to thinking of controllers in desktop apps as rarely-destroyed objects which do a lot of communication with each other.
The Rails-style controller could just be called "RequestHandler" or something like that, IMO.
It's actually kind of funny when you tell Java/C++ guys about how each time PHP receives a request, fires everything up from scratch, does the work, and then throws it all away. A fresh start each time.
Jaw, meet floor.
What's even funnier is that in javaland they took advantage of long-lived objects by having deep and broad class hierarchies, with all code in instantiated objects ... which the PHP community emulated in their frameworks, instantiating a bazillion objects on every request just to throw them away immediately. IMHO it's no surprise that in the techempower benchmarks raw php is orders of magnitude faster than a symfony implementation.
From my investigations, a lot of the time symphony spends just using the classloader. i.e., it can't load dependencies fast enough.
Generally, Servlets were multi-use objects that would serve many requests simultaneously. Except that in the early days, you could tag a Servlet as a SingleThreadModel which would tell the container to only allow one request at a time to be served by an instance of the Servlet. Lots of requests led to lots of instantiations.
This was seen as a terrible practice, whose sole benefit was to allow lazy programmers to have state variables in their controllers, and was promptly deprecated. Only to have Rails and other similar frameworks basically pick it up!