Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 6 years ago.

I've been using ASP.Net WebForms for the last year or two at work for development, but I've used PHP for personal projects for 10 years. So, I'm far more adept at developing with PHP.

When it comes to ASP.Net MVC, I have no experience with it because I've avoided it because I assumed it would just be a more complicated form of WebForms. Recently, I've been doing more research and it's sounding like MVC might be closer to what what I want. But, something I'm still not clear on is which ASP.Net programming model is closer to developing with PHP.

My biggest complaint about ASP.Net WebForms is the "magic boxes." Namely the View State, and ScriptManager.

I don't like that WebForms messes with my client side HTML/JavaScript/CSS. WebForms does a lot of this including, but not limited to:

Inserting JavaScript that I can't modify and have to rely on Microsoft to ensure cross-browser compatibility.

Forcefully changing the name attributes of tags that make use of runat="server".

Wrapping the contents of a <form> with a <div> tag.

Forcing wrapping everything inside one big <form> tag.

Everything in WebForms feels like it's catered to in-experienced web-developers who only know how to write Windows applications with .Net.

Standard names for tags and attributes are changed when using <asp:xxx> tags. For example, instead of an anchor (<a>) tag, it's a "hyperlink" (i.e. <asp:HyperLink>). Instead of href= it's NavigationUrl=.

The event driven model.

I also don't like the complete separation of server side code from the client side code. I miss being able to do things like this...

I'm not going to answer this because it would be very opinion based. All I can suggest is that you go with MVC. It's a good framework and it allows you to do the server-side/client-side mix that you seek. At least give it a try.
– Rowan FreemanSep 19 '13 at 6:06

@RowanFreema, thanks for the suggestion. The type of answer I was looking for though would not be an opinion based one. It would either say "these annoyances exist in MVC" or "they don't."
– Drew ChapinSep 19 '13 at 12:26

MVC is probably a bit closer to PHP then Web Forms. The "annoyances" you specifically ask about in reference to Web Forms mostly do not exist in MVC. However, its important to note that although MVC is closer to PHP than Web Forms it is still significantly different than building a web page in PHP.

There are specific conventions you follow in ASP.NET MVC. It still forces separate server side and "client side" code as you call it. It does, however, encourage keeping presentation logic out of the controller and in the view while keeping all non-presentation logic out of the view and in other places (controller, model, service layer, etc...).

Pages in ASP.NET MVC are route driven rather than file driven. This is a major difference between base PHP and ASP.NET MVC.

Unless you've programmed an MVC structured website in PHP you're still likely to find many of the concepts in ASP.NET MVC foreign, even if some of the annoyances you reference are not present. Vanilla PHP (without any additional framework) is much more comparable in programming model to classic ASP. ASP.NET MVC is more comparable to Ruby on Rails than anything else. Not sure that ASP.NET Web Forms is really comparable to anything.

MVC gets you closer but it is still vastly more formal than PHP really wants to be unless you are using a MVC framework. What is more equivalent to a typical, raw PHP app would be ASP.NET Web Pages. That will support inline code as shown above without the framework and ceremony MVC requires -- down to not needing a separate controller file. Microsoft also packages many of helper libraries so you can integrate things like Facebook or twitter by doing little more than writing @Facebook.Like() in your code.

I have recently read pro_asp.net_mvc_4_4th_edition and it adressed a lot of your points - I would say MVC was specifically designed to AVOID the problems you mentioned.
if you want a nice and comprehensive introduction I would give the book a try, it is very well written.