Code-behind philosophy challenged by Whidbey

I've been playing with Whidbey and experimenting a bit, in part for the book I think I'm writing, and also to start fleshing out how I'll build POP Forums for Whidbey. I think I need to make a design decision from the start, but because of the new IDE's abilities, what was once obvious isn't anymore.

In the current version of the forums, there are base classes that do most of the heavy lifting and logic in the app, including all of the data caching. Upstream there is a data provider, and downstream is the UI, which I even distribute in a separate download. The UI package consists of lots of user controls, their code-behinds, a global class, web.config and a style sheet.

The UI is the sticking point right now. It has been generally accepted to this point that putting all of your code in the code-behind is The Right Thing To Do® because it clearly separates presentation from logic. I agree with this for the most part. However, I start to challenge this to a certain degree, because quite honestly, every code-behind class I've ever used was written specifically for that page/user control. I've used special base classes derived from Page or UserControl, sure, and those get their own file. The question is, in the world of Whidbey, does it matter anymore? You can do a code block right on the page/UC with Intellisense and all, and it's going to be written just for that page.

I don't advocate ASP.old spaghetti-style code... let me be clear about that. But the point here is that the code that has traditionally been in code-behind does things like turning the visibility off of a panel or binding some object's junk to a grid or whatever. It'll never be reused, and the heavy lifting is still in the app's base classes.

Code-behind:

  • Code is compiled to assembly
  • .cs/.vb files need not be deployed
  • Clear separation of UI elements and logic
  • Intellisense (in current versions of VS)

On-page code block:

  • Fewer files to maintain
  • Easier to debug if you don't have VS
  • Easier to support because errors on live sites will show line numbers (if configured)
  • Easier for the novice to modify
  • No need to rebuild when changed

What do you think?

13 Comments

  • Well, it doesn't have to be in the same file - that just happens to be the default option in the Alpha Version. The code-beside model (using Partial Classes) in Whidbey is a great improvement though. Code beside is still compiled to an assembly...

  • But code-behind in Whidbey (also now called code-beside) does require the cs/vb files to be deployed, which is compiled on demand, and which no longer needs to be manually rebuilt when you make small changes. Of course there is also a way to pre-compile, but so far with Whidbey this also pre-compiles the aspx pages and only leaves a stub so that you can no longer make even aspx changes on the fly! I'm hoping there will be an in-between state, like we have right now, that only pre-compiles the code-behind, but I haven't heard anything that has acknowledged even the need for it.

  • I realize what VS is doing by default... that's not the issue. The issue is what's best (and easiest) for my audience. Those of us that are more experienced often forget the vast majority out there who don't yet have the same skills.



    There's a reason that the "official" ASP.NET forums are not as popular as they could be, and where you do see them deployed they haven't been altered in any way. You have to know what you're doing and understand a lot of things that the novice wouldn't to hack in there and change stuff.

  • To be honest, I think the 'official' ASP.NET forums are just fine - the Starter Kits are more designed for learning from whereas for forums are primarily designed to run the ASP.NET forums. Personally, I like the design, it really is a pretty nice, scalable and extensible design which would be pretty difficult to duplicate using in-line coding. Personally, I don't use the in-line coding approach in my applications - priamrily because I like to maintain the separation inherent in using code-behind (the View-Helper approach).

  • I have grown accustomed to the code-behind model and don't like the looks of the way it seems Whidbey may force me to work. Currently, all 'real' code goes into my code-behind cs files and all I deploy from the test to production servers are the aspx, asax, and config files. Any minor changes in the layout can be done in the aspx without recompile, but that isn't an issue for me because all changes are first done on the test server and the compilation on the local network isn't time-consuming at all. I deploy from test to production servers using Steve Sharrock's ASP.NET FTP Deployment tool (http://www.dotnetftp.com ), which automatically selected any changed files and skips cs, resx, and other files not needed on the production server.



    I know that Whidbey is going to have built-in functionality to replace Sharrock's tool, but will I now have to deploy *all* files to the production server?

  • Pretty obvious, but with separate files you can have a designer work on the HTML, layout etc. without having to worry about him/her making a mess of your vb or cs code.

  • Shannon, Whidbey doesn't force you to work in either way - code beside does rule (you don't have to declare controls in the 'code ' file etc...) - you can continue to work as-is you can even keep using code-behind if you really want to (I personally can't wait for code-beside to arrive). In short, Whidbey gives you more options - but it never forces you into a way of working...

  • I still think you guys aren't seeing the flip side. Forum applications, I'd venture to say 95% of the time, are on sites run by someone catering to a niche audience. They don't have "designers" and "programmers," there's one guy/girl. They aren't building enterprise-class n-tier applications.



    The IBuySpy and starter kits have code all over the place. It kind of sends a mixed message about what you're "supposed to do." Certainly I just assume keep everything as is, but only because it makes sense to me. I like using code-behind as well. I suppose I can offer different versions in different configurations, since it's just grunt work to move the code around.

  • I don't really agree with the approach you're espousing - it's very much the approach which used to be taken with ASP - so lots of code in-line. The Web Matrix approach is a lot more like the one you mention so mixed code / presentation and I aggree is ideal for the 'hobbyist' - but I really do not think it's necessarily the 'best' approach in terms of flexibility and / or security for anything like commercial level applications (which after all the market to which Microsoft sell their Servers - and therefore ASP.NET). The code-beside model which Whidbey allows in my opinion really does give the best of both worlds - it really 'feels' like you're working on a single file - but it does require compilation (which catches many errors).

  • Asp.Net does not even come close to separating logic from presentation. The fact that you can have two files, one with code and one with HTML does not make it an MVC platform, those two files (logic and presentation) are stil tied together. And don't even get me started on post backs (to the same page that generated the input view).

  • I agree with Jerry. Suggesting that code-behind really seperates anything I think is being liberal with your interpretation.



    Having a code block at the top of your page is NOT like ASP.old, not by a long shot. It's not inline code, it's a block at the top. I think there's a huge difference.



    Remember... I agree that "the right way" is with traditional code-behind, but you can't really identify what's right and wrong without really exploring the good AND bad with the opposing view.

  • I like using the code-behind methodology. It's easier to read, and easier for me to maintain. The idea of mixing all of my HTML code with my methods is not very appealing. This scrolling through the code and reviewing it a hassle, unlike now where I know that all of my presentation stuff is on one page, while my methods are on another. While the term "separation" might be considered liberal, I think of it as somewhat accurate. It is separating the HTML/presentation code into another file, and away from most of the "hard code" stuff that makes it go. I hated the days of scrolling around in Vis Interdev to get things done, and while the current idea isn't quite the same (mixing bindings with the HTML constantly, rather that simply performing this at the top of the page with the rest of the handling code), it still feels the same.

  • I wouldn't call it "seperation" in the same sense that a DAL and a BL Layer are seperated, but the code for the aspx page *is* seperated more when using the code-behind model than using inline. I honestly don't know how Dreamweaver handles inline code but my graphic designers have no problem at all diving into aspx pages right now using the codebehind model and the fact that the "real" code is in the .cs files makes me a lot more confident because those guys know not to touch anything other than aspx files.

Comments have been disabled for this content.