Comparison of JSP Scriptlet versus MVC with regards to performance

I came from an interview and the CTO (Chief Technology Officer) told me that there have a system (which has been running for over 5 years) and they still prefer not to use MVC purely on performance. I know most MVC uses reflection to invoke methods (which is, in essence slow) but many MVC (I know Struts does it, I read the code) cache the methods it invokes so I doesn't have to "find" the method to invoke all the time.

For开发者_运维问答 now, they stick to scriptlets (and they don't use JSPTags). I wonder, is there a huge performance going purely scriplets than MVC? They prefer stateless vs stateful sessions to avoid session migration, session tracking, etc.

If what the CTO says is true, why is MVC still preferred (I know why MVC is there, but with regards to performance).

Contra arguments:

• Reflection isn't that slow anymore since a good couple of years.
• Hardware performance has insanely been increased the last couple of years.
• MVC leads finally to faster development. Less wasted time = more $$$ saves.

I'd pass the job.

That's rather strange logic from the CTO; I don't think he knows what he's talking about (hint: pass the job!) If he's so worried about efficiency, why not rewrite the whole webapp in assembly language?

Arguments against scriptlets

• I don't like scriptlets because they are notoriously difficult to maintain. They are also prone to abuse. The biggest thing is also that they mix up view-logic with business-logic, or at the very least, make it extremely easy and tempting to do the same.

• You could judiciously separate out your concerns and use services that pull in data (and thus promote re-use). But more often than not, I've seen developers write JSPs like PHP code (i.e., code mixed in with markup).

I am not saying that you can't write good code with JSPs. It's just that it's harder (I feel MVC has more safeguards) and also (I feel) JSP's are more prone to abuse.

Arguments for MCV

• To answer your second question, MVC is preferred because by nature, it promotes separation of concerns and doesn't allow logic from the separate areas to bleed into the other areas.

• The view layer is solely concerned with rendering the view. You get metadata from your controller, and you display the data using the view. You are not concerned about the business logic here (and you shouldn't be).

• The controller acts like a traffic-cop, redirecting your requests to their proper destinations. Controllers usually end up calling services that perform all the business logic.

• The model is in charge of the data and behavior of the application domain. The model will respond to requests about its state (so this is the metadata that you're sending to the view) and will also respond to instructions that tell it to change state (from the controller).

• Reflection really isn't that slow. Also, computers are pretty fast these days and come with a lot of memory. Performance isn't that much of a concern.

• The MVC pattern promotes a clean separation between the different concerns that makes it easy for the developer to write clean, robust, and maintainable code.

Advantages of MVC over scriptlets is perfectly described in other answers, but one point is missed.

Reflection introduces some an overhead compared to direct method calls. It matters when you use reflection to call simple methods frequently. But overhead introduced by a single reflective call doesn't matter compared to the overall request processing time in a typical web application. Therefore decision not to use reflection for performance reasons in this particular case sounds strange.