Ok change of mind!! I think the MVC Framework is great for people who dont understand how to use WebForms and strugle to understand the page cycle eyc! The MVC model is much simpler to use.
That perfectly highlights your basic opinion. I for one love the new MVC way of handling things and I had absolutely no trouble understanding the page lifecycle. I never liked it, never liked viewstate, pages got bloated. In fact I would have to say that
Webforms are great for people that don't understand how to manipulate the stateless nature of the web. Webforms injects a pseudo state into a stateless entity. The idea of RESTful web apps and other such notions that many other frameworks employ was not followed
by asp.net. Of course, its fine that MS went in a different direction, but for those of us who would rather have full control of their html, MVC is a better option. Webforms creates a sense of security against having to understand html, while some may like
that approach, it is no way a superior approach which would make MVC the lesser paradigm.
Remember if you have gotten your answer to mark your thread as answered.
I have a 4 comments. please read through before flaming *wink and a smile*
1) People tend to complain about "logic in the view" and talk about "logic vs markup". They say that "logic doesn't belong in the view", but whether you're using controls or code blocks, you're still using logic. The point is, this logic is "view logic"
which absolutely belongs inside the view (whether it's hidden inside controls or visible in code blocks)
DavidKiff
[GridView exmaple]
Less lines of code!! No foreach logic within the markup! The only advantage I can see that the MVC view has is type-safty! If you really want complete control over you code why not use a repeater? That is the reason they are designed!!
You forgot the lines of code which bind the GridView to a data source. Whether you're defining your data source declaratively, or in code behind, (apart from more lines of code) you're separating it from the grid which makes it a little less discoverable.
You're right in saying that the foreach isn't in the markup, but the "logic" is still there, you've just hidden it inside your GridView. This just means you need to understand what your controls are doing behind the scenes, where as "foreach" and "if" can
almost be read in english.
2) You mentioned type-safety. Absolutely! But more than that.
a) With data binding you're performing reflection on the data source, so our "type safety" has a significant performance gain.
b) The code is visible to refactoring tools (like Resharper, but not VS?! lol) so when you refactor your data types, Resharper can update the references in your view, but it won't touch things like Eval("el.Value").
c) Intellisense
3) Don't get me wrong, I'm not saying you should use code blocks everywhere. If you do, you're bound create a maintenance nightmare (I've been there). We need a little help. And for this, we have helper methods. HtmlHelper is full of neat little nuggets
of html which we can just drop into our pages. We can even avoid using reflection on our data sources by passing delegates to our helper methods (I'm pretty sure this will be implemented in a future release of the framework but you can write it yourself for
now). You can't exactly pass delegates to a control!
You're still using <%%> tho, but Html.TextBox() feels more like a control.
4) You asked "why not use a repeater?", you can. And, assuming the MVC team haven't changed their minds, you'll be able to use <mvc: controls just like the <asp: ones you're used to. They'll output nice html but obviously won't respond to postback events
etc. They will apparently be wrappers around the HtmlHelper methods (from what I heard).
Plus you can still use your own controls and put some logic in the code behind, as long as you're careful not to expect the WebForms postback model. But a lot of people here frown on using code behind, especially since we don't have to any more.
But as Scott Hanselman said "We've already got a Repeater, it's called "foreach"."
Yea, this is a good discussion. I personally use a combination of inline code, HTML helpers and server controls. For reason already mentioned in this thread (refactoring, type safey, etc..), I always use inline code when referencing the model. But I
do like to use server controls for common HTML blocks. For example, here is a some of code for a simple form.
I am using the FieldContainer control to wrap the fields with the appropriate div's and labels. I probably could have created a helper method like Html.FieldContainer("FirstNameCt", "First Name", true). But I found the server control easier to read. In
the end, my goal is to create code that easy to read (discoverable) and maitain.
To answer the original posters question, I don't see anything wrong with using code blocks for the diplay logic. Code blocks gives us type safety, the abililty to refactor, and better performance. Can it be misused? Sure, but so can server controls.
On a side note, since we do not have to deal with ViewState and post backs in MVC, creating server controls is much easier :)
Good answers Michael Carman and tgmdbm. tgmdbm I think you've changed my my opinion of inline code blocks.
tgmdbm
The point is, this logic is "view logic" which absolutely belongs inside the view
Absolutly right, however should the logic be extracted away from the mark-up? In WebForms there is still view logic but its not mixed in the HTML its nicely placed inthe codebehind.. or abstracted away into the server controls themselves.
Saying this you have made some really interesting advantages that seem to out weight the non-seperation of GUI logic and markup.. The perfomance gain one is rather obvious.. now you have mentioned it! and then the light "weightness" of everything seems
cool.. why have a resource eating gridview when you dont use half the features..hmm
Thanks alot for the input this is what I was after in the first place! [:D]
I work in an agile shop. We examine the value for each piece--even separation of concerns.
Don't do things academically. Do them because they matter and bring value.
For a quick UI, to get feedback from the user, we'll put it ALL on the page using prototype.js.
If the logic is ONLY about UI, that's where it belongs. That's where you develop it and test it, so maitain it there.
If the app uses the database to the point the controller would start to look like a repository, guess what, we need a repository.
The value should be what drives development. Patterns are just another tool in your belt.
If it's easy to maintain and refactor, it's the right pattern for this app--maybe not the next one.
Don't allow a history of bad apps in code blocks steer you just because you see the reminding <%
If it's hard to do it right, you have habitually done it wrong.
Just write the test.
however should the logic be extracted away from the mark-up?
This is a choice for you as a developer. As Micheal suggests it's all about readability.
First of all, do not be afraid of code blocks, they are your friend! But if you think your code blocks aren't very readable, try putting it in a helper method. If your helper methods don't do it for you, create a control for it.
I think it would be nice if the MVC team put out a few more helper methods and a few controls that would help the developers who do not want to put logic in their vies avoid it. As for those who don't mind and prefer more control over the output using inline
code is fine. It is not like classic asp, as many have said, becuase it is only view logic. It is also different than asp because in the end it uses the Asp.Net pipeline and gets precompiled making it run faster and less buggy.
I played around with the webforms view engine and i was able to add server side controls and it ran very nicely. I used a server side form and agrid view in my test and it rendered like any webforms page would. I added a button to see what the postback would
od and it caused a regular MVC pattern. It seems that should one really like webforms but still want to use MVC they could be used together. This does seem to have some serious performance issues because now yoy have to run the MVC pattern and the regular
pagecycle and render a control tree, but if this is not an issue in your case using server controls seemed to work fine in MVC
I believe part of the problem is that some people find there is a smell with the
ASP.NET view engine. There are other view engines that are out there. I haven't had a chance to try any out with ASP.NET MVC yet. The nhaml project looks really cool and that is probably at the top of my list to try:
http://andrewpeters.net/2007/12/19/introducing-nhaml-an-aspnet-mvc-view-engine/.
I hear that nvelocity also works with asp.net mvc but I haven't seen this in action either. I've used nvelocity with monorail and although I think the master page concept works better in the ASP.NET view engine nvelocity has a lot more readability.
I would like to see Microsoft put some effort into a new view engine. Trying to make use of the existing ASP.NET one is all well and good to get things going and help converts, but I find it very hard to use and maintain for MVC style apps.
Preferable not. The best thing Microsoft can do is to do as little work on view-engines as possible, and focus on the framework instead.
Personaly I prefer the current viewengine, but if I wanted a XML look'alike engine, I would use XSL(T) , definitive. The problem is, no view engines besides
the current ASP.NET viewengine offers enough flexibility for the amount of different browsers and operativ-systemers.
And then we can start talking about browser specific features, DOM scripting etc. From my point of view, the majority who were extremly happy with webforms,
where the people who made websites for Internet Explorer only. But since this violates laws in now several European countries , it's not a valid argument anymore for ANYONE.
And in reality, you are likely to end up writing LESS code using the default view engine, compared to WebForms. Lambda expressions and ViewHelpers are a godly combination.
Agreed. I've become very comfortable very quickly with the combination of regular XHTML, code blocks (in small doses) and HtmlHelpers. I have long been gravitating toward having more and more output control than the more popular webforms-based controls
give you anyway.
That said, as Scott Hanselman says, it's really all about choice. Anyone who prefers controls... frankly, it's *trivial* to throw together a wrapper around HtmlHelpers if all you're trying to do is get away from the <% %> syntax. If complex controls are
your bag, then it's somewhat easier (imo) to build mvc-compliant controls than it is to build webforms-based controls, since it's closer to a 'pure' class (in that it doesn't have things like viewstate or controlstate to manage). You're basically just building
a simple string parsing engine at that point... Finally, if you're not interested in building your own controls, I'm sure it's not too long after this thing gets released (remember, we *are* talking about beta software...) that you see guys like Telerik and
RadControls coming up with MVC-compliant complex controls.
Paul
Help those who have helped you... remember to "Mark as Answered"
jbardrof
Member
638 Points
192 Posts
Re: Code Blocks vs. Code Behind
Mar 28, 2008 08:21 PM|LINK
That perfectly highlights your basic opinion. I for one love the new MVC way of handling things and I had absolutely no trouble understanding the page lifecycle. I never liked it, never liked viewstate, pages got bloated. In fact I would have to say that Webforms are great for people that don't understand how to manipulate the stateless nature of the web. Webforms injects a pseudo state into a stateless entity. The idea of RESTful web apps and other such notions that many other frameworks employ was not followed by asp.net. Of course, its fine that MS went in a different direction, but for those of us who would rather have full control of their html, MVC is a better option. Webforms creates a sense of security against having to understand html, while some may like that approach, it is no way a superior approach which would make MVC the lesser paradigm.
tgmdbm
Contributor
4392 Points
883 Posts
ASPInsiders
MVP
Re: Code Blocks vs. Code Behind
Mar 29, 2008 01:06 AM|LINK
Great discussion guys.
I have a 4 comments. please read through before flaming *wink and a smile*
1) People tend to complain about "logic in the view" and talk about "logic vs markup". They say that "logic doesn't belong in the view", but whether you're using controls or code blocks, you're still using logic. The point is, this logic is "view logic" which absolutely belongs inside the view (whether it's hidden inside controls or visible in code blocks)
You forgot the lines of code which bind the GridView to a data source. Whether you're defining your data source declaratively, or in code behind, (apart from more lines of code) you're separating it from the grid which makes it a little less discoverable. You're right in saying that the foreach isn't in the markup, but the "logic" is still there, you've just hidden it inside your GridView. This just means you need to understand what your controls are doing behind the scenes, where as "foreach" and "if" can almost be read in english.
2) You mentioned type-safety. Absolutely! But more than that.
a) With data binding you're performing reflection on the data source, so our "type safety" has a significant performance gain.
b) The code is visible to refactoring tools (like Resharper, but not VS?! lol) so when you refactor your data types, Resharper can update the references in your view, but it won't touch things like Eval("el.Value").
c) Intellisense
3) Don't get me wrong, I'm not saying you should use code blocks everywhere. If you do, you're bound create a maintenance nightmare (I've been there). We need a little help. And for this, we have helper methods. HtmlHelper is full of neat little nuggets of html which we can just drop into our pages. We can even avoid using reflection on our data sources by passing delegates to our helper methods (I'm pretty sure this will be implemented in a future release of the framework but you can write it yourself for now). You can't exactly pass delegates to a control!
You're still using <%%> tho, but Html.TextBox() feels more like a control.
4) You asked "why not use a repeater?", you can. And, assuming the MVC team haven't changed their minds, you'll be able to use <mvc: controls just like the <asp: ones you're used to. They'll output nice html but obviously won't respond to postback events etc. They will apparently be wrappers around the HtmlHelper methods (from what I heard).
Plus you can still use your own controls and put some logic in the code behind, as long as you're careful not to expect the WebForms postback model. But a lot of people here frown on using code behind, especially since we don't have to any more.
But as Scott Hanselman said "We've already got a Repeater, it's called "foreach"."
Michael Carman
Member
20 Points
5 Posts
Re: Code Blocks vs. Code Behind
Mar 29, 2008 05:44 AM|LINK
Yea, this is a good discussion. I personally use a combination of inline code, HTML helpers and server controls. For reason already mentioned in this thread (refactoring, type safey, etc..), I always use inline code when referencing the model. But I do like to use server controls for common HTML blocks. For example, here is a some of code for a simple form.
<form action="<%=Url.Action(new {action="SaveContact", id=ViewData.ContactId})%>" method="post" id="ContactForm"> <ui:FieldContainer ID="FirstNameCt" Label="First Name" Required="true" runat="server"> <input type="text" name="FirstName" value="<%= ViewData.FirstName %>" maxlength="50" size="50" /> </ui:FieldContainer> <ui:FieldContainer ID="LastNameCt" Label="Last Name" Required="true" runat="server"> <input type="text" name="LastName" value="<%= ViewData.LastName %>" maxlength="50" size="50" /> </ui:FieldContainer> <div class="buttonContainer"> <button type="submit"><span>Save</span></button> </div> </form>I am using the FieldContainer control to wrap the fields with the appropriate div's and labels. I probably could have created a helper method like Html.FieldContainer("FirstNameCt", "First Name", true). But I found the server control easier to read. In the end, my goal is to create code that easy to read (discoverable) and maitain.
To answer the original posters question, I don't see anything wrong with using code blocks for the diplay logic. Code blocks gives us type safety, the abililty to refactor, and better performance. Can it be misused? Sure, but so can server controls.
On a side note, since we do not have to deal with ViewState and post backs in MVC, creating server controls is much easier :)
DavidKiff
Star
8660 Points
1733 Posts
Re: Code Blocks vs. Code Behind
Mar 29, 2008 11:20 AM|LINK
Hey,
Good answers Michael Carman and tgmdbm. tgmdbm I think you've changed my my opinion of inline code blocks.
Absolutly right, however should the logic be extracted away from the mark-up? In WebForms there is still view logic but its not mixed in the HTML its nicely placed inthe codebehind.. or abstracted away into the server controls themselves.
Saying this you have made some really interesting advantages that seem to out weight the non-seperation of GUI logic and markup.. The perfomance gain one is rather obvious.. now you have mentioned it! and then the light "weightness" of everything seems cool.. why have a resource eating gridview when you dont use half the features..hmm
Thanks alot for the input this is what I was after in the first place! [:D]
David
Visit my site
Follow me on Twitter
tcox
Member
4 Points
2 Posts
Re: Code Blocks vs. Code Behind
Mar 29, 2008 02:36 PM|LINK
I work in an agile shop. We examine the value for each piece--even separation of concerns.
Don't do things academically. Do them because they matter and bring value.
For a quick UI, to get feedback from the user, we'll put it ALL on the page using prototype.js.
If the logic is ONLY about UI, that's where it belongs. That's where you develop it and test it, so maitain it there.
If the app uses the database to the point the controller would start to look like a repository, guess what, we need a repository.
The value should be what drives development. Patterns are just another tool in your belt.
If it's easy to maintain and refactor, it's the right pattern for this app--maybe not the next one.
Don't allow a history of bad apps in code blocks steer you just because you see the reminding <%
Just write the test.
tgmdbm
Contributor
4392 Points
883 Posts
ASPInsiders
MVP
Re: Code Blocks vs. Code Behind
Mar 29, 2008 06:59 PM|LINK
This is a choice for you as a developer. As Micheal suggests it's all about readability.
First of all, do not be afraid of code blocks, they are your friend! But if you think your code blocks aren't very readable, try putting it in a helper method. If your helper methods don't do it for you, create a control for it.
You have so much choice. Experiment.
srulyt
Participant
1073 Points
230 Posts
Re: Code Blocks vs. Code Behind
Mar 29, 2008 07:19 PM|LINK
I think it would be nice if the MVC team put out a few more helper methods and a few controls that would help the developers who do not want to put logic in their vies avoid it. As for those who don't mind and prefer more control over the output using inline code is fine. It is not like classic asp, as many have said, becuase it is only view logic. It is also different than asp because in the end it uses the Asp.Net pipeline and gets precompiled making it run faster and less buggy.
I played around with the webforms view engine and i was able to add server side controls and it ran very nicely. I used a server side form and agrid view in my test and it rendered like any webforms page would. I added a button to see what the postback would od and it caused a regular MVC pattern. It seems that should one really like webforms but still want to use MVC they could be used together. This does seem to have some serious performance issues because now yoy have to run the MVC pattern and the regular pagecycle and render a control tree, but if this is not an issue in your case using server controls seemed to work fine in MVC
superevanc
Member
117 Points
50 Posts
Re: Code Blocks vs. Code Behind
Apr 02, 2008 02:38 PM|LINK
I believe part of the problem is that some people find there is a smell with the ASP.NET view engine. There are other view engines that are out there. I haven't had a chance to try any out with ASP.NET MVC yet. The nhaml project looks really cool and that is probably at the top of my list to try: http://andrewpeters.net/2007/12/19/introducing-nhaml-an-aspnet-mvc-view-engine/.
I hear that nvelocity also works with asp.net mvc but I haven't seen this in action either. I've used nvelocity with monorail and although I think the master page concept works better in the ASP.NET view engine nvelocity has a lot more readability.
I would like to see Microsoft put some effort into a new view engine. Trying to make use of the existing ASP.NET one is all well and good to get things going and help converts, but I find it very hard to use and maintain for MVC style apps.
ASP.NET MVC view asp mvc
TheDeathArt
Member
123 Points
50 Posts
Re: Code Blocks vs. Code Behind
Apr 03, 2008 08:39 AM|LINK
Preferable not. The best thing Microsoft can do is to do as little work on view-engines as possible, and focus on the framework instead.
Personaly I prefer the current viewengine, but if I wanted a XML look'alike engine, I would use XSL(T) , definitive. The problem is, no view engines besides
the current ASP.NET viewengine offers enough flexibility for the amount of different browsers and operativ-systemers.
And then we can start talking about browser specific features, DOM scripting etc. From my point of view, the majority who were extremly happy with webforms,
where the people who made websites for Internet Explorer only. But since this violates laws in now several European countries , it's not a valid argument anymore for ANYONE.
And in reality, you are likely to end up writing LESS code using the default view engine, compared to WebForms. Lambda expressions and ViewHelpers are a godly combination.
paul.vencill
Contributor
6716 Points
1358 Posts
Re: Code Blocks vs. Code Behind
Apr 03, 2008 01:23 PM|LINK
Agreed. I've become very comfortable very quickly with the combination of regular XHTML, code blocks (in small doses) and HtmlHelpers. I have long been gravitating toward having more and more output control than the more popular webforms-based controls give you anyway.
That said, as Scott Hanselman says, it's really all about choice. Anyone who prefers controls... frankly, it's *trivial* to throw together a wrapper around HtmlHelpers if all you're trying to do is get away from the <% %> syntax. If complex controls are your bag, then it's somewhat easier (imo) to build mvc-compliant controls than it is to build webforms-based controls, since it's closer to a 'pure' class (in that it doesn't have things like viewstate or controlstate to manage). You're basically just building a simple string parsing engine at that point... Finally, if you're not interested in building your own controls, I'm sure it's not too long after this thing gets released (remember, we *are* talking about beta software...) that you see guys like Telerik and RadControls coming up with MVC-compliant complex controls.
Paul