How do I throw a textbox on the listing page with a button and do a simple search. In asp.net, I would throw a textbox, button and grid on the page and bind it to a sproc and away I go
That's exactly the biggest problem behind "classic" ASP.NET aka WebForms.
You shouldn't be thinking in terms of pages, buttons and events.
You should learn the basics of how web works. Then you'd understand that the web speaks in terms of HTTP protocol, its commands GET, POST and others. Presentation is HTML, CSS and the Document Object Model which is where JavaScript comes into play. And there are in fact no pages, an url is just a pointer to a resource which is not necessarily mapped to a physical file (.html or .aspx) on the server.
the View page of MVC brings back nightmares of classic asp with all the in-line code that we got away from way back when with code behind pages.
I also came to MVC after staying with WebForms and I discovered I like the inline code very much. It makes the view structure very clear, which cannot be said about the coupling of static markup (aspx) + manipulating server controls in code-behind. The latter is actually a nightmare - your code is generating the markup output but you don't see where and how.
What can MVC bring to the table that we can't do in asp.net or MVC can do faster
It removes the ugly stateful abstraction which WebForms gave us. You're now back where it started. What you have now is:
Option to separate your presentation part (views) from your application logic. Before there was all mixed together, code-behind talking to the database, calling other services, modifying the markup. It was mess. It resulted in lots of serious applications written but hardly maintainable any more.
Ability to automatically test your application logic. With WebForms and code-behind, how would you invoke a certain scenario? You'd use tools like Selenium to mimic user activities. Now, when your views are just a passive presentation layer, you don't have this problem any more. You test your business logic and model output very easily. Views are there to display the results. If the model got the correct data in a particular scenario, the view will display it correctly. If not then not. Period. No need to test views.
Control over your markup. That is if you care. If you a former Windows developer who doesn't give a damn about HTML documents being valid, being semantically correct and optimized for web engines, then it's of no use to you. I mean, "pages" are sort of displayed, user clicks are processed like in desktop application, what else, right? But if you were interested in all those things, then you'd look at the final markup output and see that it is ugly, with lots of errors, limitations which you simply can't fix. Because it's how controls, buttons, data grids etc. display themselves. An attempt to fix them would require to override markup generation of those controls which is a heavy task. Why don't just drop it and do everything manually?
What MVC takes from the table?
A server-side processing of "control" "events", like in Windows programming. If you're developing a desktop-like application for web medium, like those typical "business" software with dozens and hundreds of controls to drive you crazy, then MVC will drive you crazy, because you will have to wire each single control individually with JavaScript.
But if you're not developing those kinds of applications (which require certain mental abilities to work with), but developing modern usable software for web, then WebForms would drive you crazy. Sooner or later.
There are various positive points to moving towards MVC
1. TDD support out of the box as most of the design is based on interfaces.
2. SEO friendly URL by design (though now this is possible in ASP.NET 4 as well)
3. No ViewState (this may seem a bit of moving backward to some), but overall a good design decision.
4. Clean View Markup (no additional HTML emitted)
5. 100% extensible. You can add your own controller with IOC, switch view engines at will, control model binding at wish etc.
6. Rich UI support (possible through client side JS libraries like jQuery UI and others). Telerik has released some controls for MVC which includes Grid control as well (which are merely HTMLHelpers)
7. Session, JS, Ajax works. Validation is even more powerful with DataAnnotations and jquery.
8. Is MVC faster? Yes by default because of lack of viewstate and clean markup. But performance is subject and MVC by design is more performant that traditional ASP.NET webforms (though webforms can be made as fast as required.
9. Out of the box support for mitigating antiforgery attacks and XSS vulnerability (though asp.net does has this to some extent)
10. Out of the box minimal IOC support.
11. Full control over rendered HTML
12. Pluggable architecture
13. And much more....
Couple of limitations (though not exactly)
1. Learning curve as most asp.net developers are used to windows form model for web development.
NOTE: Webforms is not bad. But by design it encourages many bad practices. A webform at the hands of careful developer is as or could be even more productive than MVC. Just my thought.
Additional readings at http://msdn.microsoft.com/en-us/magazine/dd942833.aspx
Hope this helps.