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.
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!
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.
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.
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!
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."
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!
netstruc65
Member
1 Points
8 Posts
Code Blocks vs. Code Behind
Mar 28, 2008 02:56 PM|LINK
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.
ASP.NET MVC
DavidKiff
Star
8660 Points
1733 Posts
Re: Code Blocks vs. Code Behind
Mar 28, 2008 03:05 PM|LINK
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?
Visit my site
Follow me on Twitter
rjcox
Contributor
7064 Points
1444 Posts
Re: Code Blocks vs. Code Behind
Mar 28, 2008 03:10 PM|LINK
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.
DavidKiff
Star
8660 Points
1733 Posts
Re: Code Blocks vs. Code Behind
Mar 28, 2008 03:34 PM|LINK
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!
Visit my site
Follow me on Twitter
sodablue
Member
345 Points
75 Posts
Re: Code Blocks vs. Code Behind
Mar 28, 2008 04:45 PM|LINK
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.
netstruc65
Member
1 Points
8 Posts
Re: Code Blocks vs. Code Behind
Mar 28, 2008 04:52 PM|LINK
It sounds like its a personal preference whether or not you use code blocks or use the code behind.
DavidKiff
Star
8660 Points
1733 Posts
Re: Code Blocks vs. Code Behind
Mar 28, 2008 04:57 PM|LINK
Really? Mine do!! If you talking about server controls they render plain HTML.. the UI logic has been nicely extracted away from the view.
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!
Visit my site
Follow me on Twitter
DavidKiff
Star
8660 Points
1733 Posts
Re: Code Blocks vs. Code Behind
Mar 28, 2008 05:00 PM|LINK
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
Visit my site
Follow me on Twitter
DavidKiff
Star
8660 Points
1733 Posts
Re: Code Blocks vs. Code Behind
Mar 28, 2008 05:08 PM|LINK
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
Visit my site
Follow me on Twitter
andyfreestyl...
Member
171 Points
56 Posts
Re: Code Blocks vs. Code Behind
Mar 28, 2008 05:10 PM|LINK
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!