I almost started this post with “So, “, but I stopped myself. Listening to .Net Rocks, and reading other blogs, I’m beginning to lose some basic grammar ability. “So” does not belong at the beginning of a sentence (unless it’s used to mean “so that“ and preceeds a subordinate clause). It either separates two independent clauses or an independent clause and subordinate clause when meaning “so that”. Ok, on with my post.
.Net 1.0 comes out, and everyone jumps on the bandwagon of code-behind (myself included). Not only is it a good idea to separate code from presentation, MS recommended it, so we did it. I don’t regret it. One thing to note: code attached to a page should only do small things e.g. bind a listbox to a source, change text of a label or TextBox, show/hide controls, input validation etc. Things that should not be done in page code are connecting to a database, reading/writing to/from a file, executing business logic or validation, etc. If the Html view of the VS.NET designer had included intellisense for code, there would have been people who never would have used code-behind, but because that was the only option that offered intellisense, that’s what we did. Choosing code in a server-side script tag or inheriting your page from a code-behing class should be developer or team preference. If you are properly separating business logic from the UI, this shouldn’t be an issue, but so many developers continue to omit business logic classes from thier applications. They connect directly from the web server to the database. They tightly couple their UI with business logic. Then, when changes need to be made, it takes longer than necessary and code reuse consists of copy and paste. Bad idea. Plus, why should an Internet-facing web server have direct access to an internal database server? That, too, is a bad idea.
Let me share with you some successes I’ve had with code-behind. Note that code-behind is just the term used for creating an intermediate class betwixt the actual page and the System.Web.UI.Page class from which they all inherit. With code-behind, you are subclassing the Page class, adding properties and methods, and then inheriting your actual page from your class. Now your page class has access to all your public or protected members. I quickly found that in a web app, many pages are going to have some of the same properties. A user object is a good example of something that every page is going to need. Why declare that property in every code-behind class? Instead I created my own MyPage class that inherits from System.Web.UI.Page. In this MyPage class, I declare the User property (with the “new” keyword to hide the base class’s User Property – my User object implements IPrincipal) and other properties and methods that need to be available throughout the application. I add code in the MyPage class to initialize the User object and do other things, and then every code-behind class inherits from MyPage. Now every page in my application benefits from this abstraction because every page can use my own User object natively. I wrote the logic once, and I can use it on every page. Now that is what object-oriented development is all about! True code reuse. I remember the days of #include in ASP 3. .Net is so much better.
To get back to the change in Whidbey, I say, welcome inline intellisense. Since my pages have little code anyway, I will probably go back to putting code in the same file. This still won’t be the same situation as ASP 3.0, however, for the code will be in a <script runat=server> tag, and won’t be inline with the Html. Also, because ASP.NET is compiled, this code will not be in the source files that are deployed on the server, so my pages will have some UI code and method calls to business objects. That’s about it.
All in all, I tend to trust Microsoft to make good decisions about the development tools. There are tons of developers working to come up with these coding methods, and I’m pretty sure that I don’t know better than the collective knowledge of the Microsoft developers.