Right, but in an MVC web-app, the Controller defines the "end-point". Meaning it should end there. The composition of different pieces of functionality should b

Right, but in an MVC web-app, the Controller defines the "end-point". Meaning it should end there. The composition of different pieces of functionality should be happening in the area of the business logic. I understand the motivation, and have come across several situations where I wanted "controllers calling controllers", but ultimately, you're repurposing a piece of the architecture to do something it shouldn't be doing. A controller handles the input into the system, it shouldn't be defining a workflow. > In a purer MVC world you get something similar to this by making a function that instantiates the login controller with its associated view; that's pretty good, but there's no obvious place to put that function. That just sounds backwards to me. Are talking about creating dynamic endpoints? That sounds like a much bigger headache than composing stuff in a service layer. MVC can be a little ambiguous, and with web-frameworks it can be hard to see that each piece is actually a subsystem. The Model isn't just your model class, its the model class, the DB and the ORM library you are running. Similarly, the View is the entire response / template rendering subsystem. The part that is addressed in the framework is mostly the "controller" subsystem, which is a way of organizing code so that the actual "controllers" can do the primary work of sanitizing input, delegating function calls and returning the output to the View system. Again, MVC is just a pattern that doesn't fit perfectly in the web request/response cycle, which then necessitates a pattern to handle the leakage (in my case I'm talking about the service/manager pattern). However, I just don't see your suggestions that MVC is "dead", or how this system is radically different. It seems like it is just semantics.