Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

A developer told me they used delegates to bind most of their events in ASP.NET. Until then, I did not even know it was possible to use delegates in ASP.NET in a meaningful way.

My understanding is that ASP.NET/MVC3 works via HTTP verbs, not events/delegates. Is it even possible to have an event fire from the client to the server? This strikes me as an invalid form of IPC.

share|improve this question

2 Answers 2

up vote 4 down vote accepted

Delegates are used in ASP.NET for binding the events from controls on the page to the functions in your code behind. If we take the ASP.NET button for example, we have the click action, command action, DataBinding action, along with Disposed, INit, Load, PreRender and Unload. All of those have delegates associated with them and if you create a function that does something with it, the delegate will point to your function.

I think the confusion is when you use the delegates. Since ASP.NET MVC3 is built on ASP.NET and is not its own beast. You will still use delegates when using input fields or any of the asp controls even when using MVC. Like maple_shaft says:

Everytime there is a postback to the server, the ASP.NET lifecycle events are fired in order, causing the server side objects to be created, updating the viewstate with the updated information from the client, updating the server side elements with data from the viewstate, executing any server side events that need to be executed, and finally rendering the HTTP response to return back to the client.

The way that the events are executed is through the use of delegates.

share|improve this answer

It does work through HTTP verbs, but the event model in ASP.NET is correct too.

ASP.NET tries to abstract the underlying complexities of HTTP stateless communication in a way that would be easy for traditional WinForms and VB developers to understand. It is debatable if they actually acheived this goal however.

For more information see the MSDN article on the ASP.NET Life Cycle

ASP.NET bridges the gap by having what is known as a ViewState exist on both the server side session and a client DOM element. Everytime there is a postback to the server, the ASP.NET lifecycle events are fired in order, causing the server side objects to be created, updating the viewstate with the updated information from the client, updating the server side elements with data from the viewstate, executing any server side events that need to be executed, and finally rendering the HTTP response to return back to the client.

The client at that point will take the updated viewstate from the server and use it to update its own DOM elements and execute client side events as necessary.

If it seems complex that is because it is. This is why many view it as a failure because it requires detailed understanding of the underlying architecture to really become good with it.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.