Why is MVC stateless - How to explain?

Question

While explaining concepts of ASP.NET MVC to my students

MVC is stateless. It is built on top of another stateless protocol - HTTP and HTTPS

But one student interrupted and asked,

You tell that the MVC is stateless

Stateless protocol never cares if the response comes back or not from the server. But, in ASP.NET MVC framework, you make a request and wait for the response. Since you wait for the response, it should be called as a stateful service. How come you are calling it a stateless service then?

I really got stuck up and wondered what to answer to this question.

Any ideas?

Answer 1

MVC is not stateless, HTTP is.

HTTP being stateless doesn't mean it is fire and forget. The client does wait for the response. It is stateless in the sense that two successive requests have no relation whatsoever.

State can be emulated using sessions, for example using cookies.

Answer 2

The assertion in the question, purported by the other student it wrong. A stateless protocol like HTTP sure does care if it gets (or never gets) a response!

[A stateless protocol] treats each request as an independent transaction that is unrelated to any previous request so that the communication consists of independent pairs of request and response.

Of course, MVC isn't even a protocol .. but the same notion can be extended. It is "stateless" insofar as all the information is encoded in the request and response as a "pair". In practice, most usages are not truly stateless.