ASP.NET MVC

Re: Code Blocks vs. Code Behind

pure.krome — Fri, 04 Apr 2008 03:21:12 GMT

great post and discussion, people :)

Re: Code Blocks vs. Code Behind

sodablue — Thu, 03 Apr 2008 16:43:39 GMT

Don't allow a history of bad apps in code blocks steer you just because you see the reminding <%

“The cat, having sat upon a hot stove lid, will not sit upon a hot stove lid again. But he won't sit upon a cold stove lid, either.” - Mark Twain

Re: Code Blocks vs. Code Behind

paul.vencill — Thu, 03 Apr 2008 13:23:36 GMT

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

Re: Code Blocks vs. Code Behind

TheDeathArt — Thu, 03 Apr 2008 08:39:25 GMT

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.

Re: Code Blocks vs. Code Behind

superevanc — Wed, 02 Apr 2008 14:38:15 GMT

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.

Re: Code Blocks vs. Code Behind

srulyt — Sat, 29 Mar 2008 19:19:53 GMT

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

Re: Code Blocks vs. Code Behind

tgmdbm — Sat, 29 Mar 2008 18:59:46 GMT

DavidKiff:
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.

You have so much choice. Experiment.

Re: Code Blocks vs. Code Behind

tcox — Sat, 29 Mar 2008 14:36:18 GMT

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 <%

Re: Code Blocks vs. Code Behind

DavidKiff — Sat, 29 Mar 2008 11:20:04 GMT

Hey,

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!

David

Re: Code Blocks vs. Code Behind

Michael Carman — Sat, 29 Mar 2008 05:44:06 GMT

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 :)

Re: Code Blocks vs. Code Behind

tgmdbm — Sat, 29 Mar 2008 01:06:07 GMT

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)

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"."

Re: Code Blocks vs. Code Behind

jbardrof — Fri, 28 Mar 2008 20:21:44 GMT

DavidKiff:
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.

Re: Code Blocks vs. Code Behind

DavidKiff — Fri, 28 Mar 2008 20:21:30 GMT

ShaneBauer:
Honestly, I stopped reading your post after the first sentence

You read the end

ShaneBauer:
so why shouldn't the application framework be simple as well

Why should it not!? To behonest as ive already said I like the MVC Framework, even written some sites in it already ! The debate im raising (educational) is it good that markup and code is mixed together?

I have come from a classic asp background into .NET and yes in the begining I struggled to understand why its better especially with the lack of control over the markup...however after three years of experiance with asp.net webforms I now understand why its better and understand you have as much control you want over the markup! If I was starting out now, I would probably perfer the MVC Framework because back then I wouldnt have understood why webforms has been made like it has.

ShaneBauer:
If you don't see the benefits, then don't use it

I do...ive used it!! You're missing my point!

ShaneBauer:
to tell someone why they should use a tool isn't beneficial for anyone

Im not telling! Im not saying dont use MVC and use webforms instead.. Im saying is it a good idea to mix markup with code? I dont mind what other people do!

ShaneBauer:
saying that a certain tool is only for people that can't understand another is ridiculous.

You have taken this out of context or I did not make my implication understandable. I was trying to say its easier for people begining asp.net development.. there is far less to learn in terms of various server side controls etc. This isnt to say its no an appropriate framework for experianced people either!!

Cheers,

Re: Code Blocks vs. Code Behind

ShaneBauer — Fri, 28 Mar 2008 19:16:55 GMT

Honestly, I stopped reading your post after the first sentence. The last part is correct, though. "The MVC model is much simpler to use." That's right. HTTP is simple, so why shouldn't the application framework be simple as well. There is no such thing as a page life cycle in HTTP. You have a responses and requests. Why should WebForms have numerous events for a single page?

WebForms is Windows forms for the Web (hence the name). WebForms wasn't created for smart people to show off their understanding of events.

Again, MVC isn't for everyone. If you don't see the benefits, then don't use it. Not everyone will like it. Spending two pages on a forum trying to tell someone why they should use a tool isn't beneficial for anyone. Coming here to spark debate and learn is one thing, but saying that a certain tool is only for people that can't understand another is ridiculous.

Re: Code Blocks vs. Code Behind

DanFinch — Fri, 28 Mar 2008 19:01:08 GMT

When I first took a look at ASP.NET MVC I was wary of the inclusion of .aspx but after working with it for a while I'm beginning to favor spaghetti code in MVC. In web forms it quickly got hairy and there's every opportunity to avoid unreadable nonsense entirely in MVC (helpers), but it's a great templating solution for people who want to work intimately with the standards, but I've found use for view-specific helper methods in code-behind which use System.Web.UI.HtmlControls. It depends on the view.