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?