The coding models in Whidbey

I'm loving all of the discussion about how we “should” write code in our ASP.NET apps in v2.0. I guess the shocker is that a ton of people are open to the inline code and partial class/code-beside model (Andy Smith got me thinking about this).

Whenever someone brings up the topic, the “purists” of course speak up and talk about how code-behind is proper or whatever. Like Andy said, I've been saying for years that the alleged code separation this model provides is a fallacy. He also said what I've been trying to put my finger on for a long time: The model suits the tool, Visual Studio, not the platform itself. Very insightful.

Between my book and thinking about POP Forums, I'm interested to see what people will consider the best practice, especially since “best practice” is part of the book's working title. My developing opinion is that the code-beside method, with the page linking to a partial class, is the best method for development in the event that you have designers and coders working separately. I think in good app design you do all of your heavy lifting in totally separate classes anyway, so I would expect that your partial classes, the glue between UI and logic, would be fairly light in code.

However, if you're a one-person development team, then I don't see any reason not to just use the inline code. Again, your code there should be minimal anyway. In fact, if you decide to get into the declarative model of coding, as the ASP.NET team seems to advocate with all of the new controls, you might have even less code on your page. Using the forums as an example, what if I had a control that you declared in the page that got a list of topics to bind to a repeater?

It's very exciting. It challenges what we've been doing, and improves on it. It gives us the options to not change at all, if that's what you're about. I can't wait for this stuff to be licensed live.