I'm currently building an ASP.Net MVC demo for our company, with the goal to win them over that it is a feasible pattern/framework for us to use.

 One thing I'm struggling with is the benefits and drawbacks to to using code blocks, <% %>, to fill the page with data, create forms, etc., versus using server controls and filling their values in the code behind. I know this is a loaded question, but any argument for or against would be welcomed.

Hey!

I would like someone to answer this as well!  To me adding inline scripting blocks (<%%>) reminds me of classic asp and therefore seems like we are taking a stepback!

Have I missed the point somewhere? 

DavidKiff:

To me adding inline scripting blocks (<%%>) reminds me of classic asp and therefore seems like we are taking a stepback!

The big difference is that in classic ASP everything was in scripting blocks, including connection strings, data access and business logic. In MVC you (should) just have presentation.

Having presentation logic in with the markup (rather than split into multiple places) means it should be easier to maintain (once devs get the hang of the style)... and the tools of user controls and code behind allow you to factor out complex logic and common elements.

Finally, in MVC use of .as?x is just the default view engine, other view engines are possible (and several have been implemented) where a cleaner approach might be possible. 

rjcox:

Having presentation logic in with the markup (rather than split into multiple places) means it should be easier to maintain (once devs get the hang of the style)... and the tools of user controls and code behind allow you to factor out complex logic and common elements.

I disagree with this.  Mixing UI logic with html is still messy.  Thats one of the good thing about webforms!  The GUI logic can be extracted away from the HTML and placed in the codebehind!

I like everything else about MVC just strugle to accept that using <%%> is a good idea!

If you use the code-behind then your going to dynamically build HTML to dump on to the screen so its still a mess!?

When you want to re-factor then its going to get really messy if its all done in the aspx! 

I don't quite buy the argument that mixing UI logic with HTML is messy, as Webforms don't really use HTML.  You use webcontrols that look like HTML but act differently.

What's nice is that by writing out the raw HTML, you have more control over it.  I used to have to jump through a lot of hoops to get a datagrid to output the table exactly how I needed it.  Especially when you have to write a lot of ugly OnDataBound() event handlers to tweak things, insert bits of javascript, or whatever.

With MVC, I can focus on the view, on what is being output.  I don't have to jump through quite so many hoops just to get HTML to output the way i want it to.

It sounds like its a personal preference whether or not you use code blocks or use the code behind.

sodablue:

as Webforms don't really use HTML

Really?  Mine do!!  If you talking about server controls they render plain HTML.. the UI logic has been nicely extracted away from the view.

sodablue:

I used to have to jump through a lot of hoops to get a datagrid to output the table exactly how I needed it. 

I guess its about finding the right tool for the job and getting to know how to use the controls!  I dont have this problem, If you wanted complete control on the output then why didnt you use a repeater control!?

You can create all the mark up you want!  The codebehinds allowed you to perform UI based logic, forexample show and hide pannels based on the views data etc and keep this extracted from the views markup.  MVC doesnt allow this because the controls in the aspx are not directly accessable in the codebehind at design time.

Theres not a great difference in using MVC Framework's inline <%%>  and writing all HTML in the code behind and dumping it to a screen! 

netstruc65:

It sounds like its a personal preference whether or not you use code blocks or use the code behind.

In some respects yes.. however you can do the samething in web forms as you can in MVC's webform view.  However theres reasons why people dont do this... abstraction being one reason

I have been digging around for answers with this now!  And found some quotes from A Microsoft Valued Person (MVP):

"We as a community have spent years persuading developer that inline code is not only bad, but in fact bordering on evil"

"The mess that Classic ASP pages could get into because of nothing more than inline code was not only shockingly prevalent within the Classic ASP community but also was a massive overhead on maintaining applications"

"One thing the MVC guys talk about is the separation of concerns which refers to the way in which you have the "model" and the "view" and the "controller" (MVC!); whilst they bang on about this, the separation of markup from code is completely disregarded as a non issue"

"Inline code makes me very wary, whenever I see someone sneaking it into an ASP.NET page they get a good bollocking about it."

Reference: http://weblogs.asp.net/plip/archive/2007/12/09/is-mvc-right-for-you.aspx

DavidKiff:

forexample show and hide pannels based on the views data etc and keep this extracted from the views markup.  MVC doesnt allow this

Extension methods can help with elegant conditional rendering in MVC - http://www.iridescence.no/Posts/Conditional-Rendering-in-AspNet-MVC-Views.aspx.

The Microsoft team appear to be focussing on the moment on the groundwork - routing, testability - a reusable component model, more html helpers will no doubt come that may be more to your liking.

As mentioned by other posters, as a Designer/Developer, I love the ability to control the exact markup in each view. Especially to get the fine grained control to couple up tags to javascript for AJAX coding. Angle brackets and inline code are your friend!

DavidKiff:

separation of markup from code is completely disregarded as a non issue

There is seperation in MVC - the Model, the View, the Controller! Inline code within the View should be for presentation only. Comparing with spaghetti code in many Classic ASP applications is a red herring, as they typically combined presentation and business logic and data access in one .asp page.

andyfreestyle:

There is seperation in MVC - the Model, the View, the Controller!

The quote said "separation of markup from code" this means yes they did a good job with the MVC part but forgot about seperating the markup (HTML) from the code (If, Else, Foreach, For etc).

andyfreestyle:

Comparing with spaghetti code in many Classic ASP applications is a red herring, as they typically combined presentation and business logic and data access in one .asp page.

Yes I agree, classic asp is much worse, but i still dont agree its good to have if, for, foreach etc mixed within the markup!! 

I see the Html helper methods as the MVC response to WebForms facilities.
Anyway, it's very useful...
 

 When you want to re-factor then its going to get really messy if its all done in the aspx!

You know, you're surposed to use strong typing and lambda expressions to allow proper reflectoring.
WebForms is just a execuse of being lazy and having no clue how to write proper HTML.

Special because WebForms rarely rendered proper html, was special annoying to get to work with custom CSS and JavaScript DOM scripting.
I suggest you adapt to this much better pratice, and forget everything you learned in webforms.

WebForms were never good performance wise anyway.

  This means yes they did a good job with the MVC part but forgot about seperating the markup (HTML) from the code (If, Else, Foreach, For etc).

If you really want, you can use XSLT instead of HTML, since it allow the common things required in a view, ie. variables and iterations.
Just write your own view engine for that, it can't take more than a few hours and you're done. To bad the performance is horrible.

You can ofcource choose clientside XSLT, rather than on-the-fly compiled xslt2xhtml , but then you have to learn the IE team how to support it properly first.
  

Personally, I think .net made developing for the web *too* easy. The IDE & its little modular controls give people the false impression that building a website is just like building an executable. They are completely different beasts and I'm finally glad that .net is taking web development in it's own direction. The MVC will share the scalability, testability, and control as other application development but will have its own flavor. For those of us that don't like the big red Easy button, this is great. It's just a matter of preference I guess... just so glad I don't have to jam html into a string anymore...