When we use cookies in an application is considered a sessionless design?
I don't completely understand what sessionless really mean.
Does it mean that the session is not stored in the server o that a session object is not used?
It depends what you mean by sessionless. The http protocol in and of itself is stateless and therefore sessionless by design. One request has no idea, concern or knowledge about the requests before nor after it. We have to layer state in if we want it.
If on the other hand you mean sessionless state then the idea here is to avoid using scarce server resources like InProc use of RAM or OutProc like Sql Server or Redis to hold sessions.
Cookies are one mechanism to achieve that. As is storing the session key in the page itself either in a hidden form field or some other aspect of the page. Storing the session key in the query string of the page is another option as is using client side sessionStorage or localStorage.
A reason why we might to do ths is because server resources are expensive and the default mechanism is also synchronous. If you're using a lot of Ajax in your page and making lots of random requests to the controller then those requests will be queued and processed synchronously because this:
session["mykey"] = "that"
is actually processed more like
lock(sessionLock)
{
session["mykey"] = "that"
}
so there will be queuing involved and depending on the app this may be an issue.
You should also note that sessions are volatile in that if the worker process running your site recycles (which they do often) all sessions are lost. So default ASP.Net session are next to useless for any real world application in which this is an issue.
So the choice is then OutProc on server, or session-less via client.
Obviously using session-less on client has security risks that have to be mitigated. So which is the best place to store sessions will be always be determined by the requirements of the application you are designing.