Good advice and I'm glad someone said it....

As a developer if you're working with this new framework you find yourself doing some of the things that Derik is ranting about you have to have the discipline and professionalism to stop yourself.  

If ever in doubt about whether you're putting too much code somewhere or in the wrong place, ask yourself if you can test it.  Even if you aren't testing....ask yourself, how you would test it.  If your code leaves you unsure and scratching your head, that may be a sign you've put code somewhere that, while works, is now legacy code a la Michael Feathers (code that isn't tested).

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Looks like people now (myself included) is realizing that ASP.NET MVC by itself is no guarantee of better systems; people can mess up with it just as bad as people can mess up with "classic" ASP.NET webforms.

So, of the 3 most commonly referred advantages of ASP.NET MVC - testability, control over HTML and separation of concerns - I would say the third one depends on the coder just as usual.

@Lerxst - re:SOC being a case of "it depends"

Clearly there is no magic bullet - or framework/toolkit/etc... - that can fix or make up for irresponsible software developers. :)

Pingback from  ASP.NET MVC Archived Buzz, Page 1

Well it's like I've always said - a pattern/tool/framework does not a good program make...

Thanks for pointing out the elephant in the room; let's hope people listen!

Agreed, especially on the point about controller != code behind. Unfortunately, a lot of the journeyman devs out there hearing about this great new Microsoft Framework called EmVeeSee look up ScottGu's demo code, and think it's Holy Writ to do all of that stuff in thier action methods...

> Create Linq2SQL context - check

> Query context - check

> Fill in entity object - check

> Save back to context - check

> Redirect to action - check

That's not a knock against Gu. It's just demo code after all, but I think I'd like to see the MS crew be a little more vocal with disclaimers like "THIS IS NOT HOW YOU'RE REALLY SUPPOSED TO DO THIS. I'M DOING BAD THINGS HERE."

Getting this kind of great guidance makes me anticipate your MVC book even more.  I'll be interested in the "how" of things, but "best practices" is also something dev's should understand and embrace.  Cheers!

You will obviously use "some" code behind such as in your Page_Load but you want to keep it to a minimum and have your controllers do the work as much as possible.

I'd take it a step further and say that when possible you should REMOVE the codebehind. YAGNI. Hope you don't mind the self-link, but I feel this is relevant to the discussion:

www.squaredroot.com/.../MVC-Strongly-Type-ViewPages-Without-A-Code-Behind.aspx

I agree with fervor -- one point though.

In order to use WebForm controls, it is (as far as I know) necessary to use limited code to state the WebForm control in the code behind file.

I'm using MSChar, DevExpress's GridView & Tab control in a MVC app.  The only way I was able to bind data to the chart & grid was to add an OnLoad event to the view's code behind file and bind data sources there.

This however, is the only code in the file.  If you or anyone else has a suggestion for handing this situation better, please post about it.

@Derik

Yes, it is true.  WebForm controls depend on both the Postback and ViewState models.  

You may also be aware that not using 3rd party controls or web form controls in general is a show-stopper for enterprise environments like I work in.

I'm not disagreeing with you.  ASP.NET MVC's philosophy makes perfect sense to me as an engineer.  However, If my company cannot leverage Webform controls at all, they'll elminate this framework completely.

To work with ASP.NET MVC,  my choices are:

- work-arounds and putting the two together.

- find another flexible company that understands the advantages of ASP.NET MVC.

The later isn't realistic IMO -- although I'd code for food if necessary.  :-)

I was suprised to find that MVC encourages <% %> in the markup.  I found this article searching for how to use asp.net server controls with MVC.  After tinkering with my own MVC app, I'm thinking: "They went to all this trouble for separation of concerns, but then went back on .net's first separation of concerns, namely separating markup from code.  This is a big deal if you have a non-developer maintianing your markup (i.e. a designer).

Rather than do this:

<input type="text" name="Title" value="<%=ViewData["FirstName"] %>" />

What about this:

MARKUP:

<input type="text" name="FirstName" runat="server" id="FirstName" />

CODE BEHIND:

public void Page_Load(object sender, System.EventArgs e)

{

    FirstName.Value = ViewData["FirstName"];

}

So what do you think of using the HTMLGeneric Controls?  it does not generate viewstate or postbacks, yet it leaves the markup to layout the page and code to determine what values go in what fields.  In my mind, this is not domain business logic, but it is the view's business logic and so SHOULD go into a code-behind.

Mark

p.s. I'm using this tip to remove the .net control tree id from form posts: code.msdn.microsoft.com/.../ProjectReleases.aspx

Mark

I disagree - as long as the codebehind is only used for simple view logic, I think it's fine.

Say my strongly-typed model is IEnumerable<User>, where User is:

string Username

string FullName

UserType Type

Then in my view I want to iterate through the IEnumerable and display the User details in a table.  I want to display each row in the table using a different colour/cssclass depending upon the UserType.

Three options spring to mind:

Use a different model with a CssClass property and put the css selection logic in the controller - IMO this is placing View code in the controller.

Place the logic in the ASPX file along with the HTML - messy.

Create a GetCssClassFromUserType() method in the codebehind file and call it from the ASPX - nice.

Feelings?

I've found that I really like using the code behind in ASP.NET MVC. I have a standard structure for how I want my forms laid out. If I build the form in the code-behind, I can re-use a bunch of stuff and have my UI compile-time checked. This also makes it much easier to update the site structure; there's only one place my data entry row is defined.

The aspx content ends up looking like this:

<%= form %>

and the aspx.cs file ends up having this in the onload:

var formItems = new IFormItem {

   Item1,

   Item2,

   Item3

}

form = Html.BuildForm<Controller>(c => c.Method(), "FormName, formItems);

This has been quite handy ... so I guess it all depends on what you're doing in the code behind.