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
MVC is not a protocol is a software architectular pattern.
On the other hand, HTTP is a protocol.
In nowadays the MVC pattern is very popular among many web frameworks. These web frameworks and the rest of other web frameworks are used for the development of web applications. In the context of web applications HTTP is an application protocol that is used from browsers for their communication with the servers that host web applications.
Indeed the nature of HTTP is stateless. There isn't anywhere in HTTP the concept of state
. For this reason, in many web frameworks, there are different ways through which we try to implement the concept of state
. For instance in ASP.NET Web Forms
the ViewState
was developed for this reason.
That being said, MVC has nothing to do with the stateless nature of HTTP.
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.
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.
Please keep in mind, that there are a lot of different implementations of the concept of a model-view-controler architecture. There is no "correct" MVC. ASP.NET MVC cannot be is not a "perfect" implementation of the model-view-controler pattern!
Otherwise of thinking of stateful/stateless MVC. MVC can be understood by thinking of responsibilities:
The View is not allowed to change the state of the model directly - only through the Controller. The view can still have some direct access to the Model although only for viewing (or by having a copy that isn't the official Model).
The Model should live in its own universe and not have any reference to controllers or to views.
The Controller controls the state and access to the Model.
How they all interact with each other, can be implemented very differently (based on the platform for example) ...