January 2008 - Posts
Over the last few weeks I've been working on finishing the latest book from SitePoint on ASP.NET, "Build Your Own ASP.NET 2.0 Web Site Using C# & VB, 2nd Edition". The authors did a great job on this book. It's fit for a beginner and does a wonderful job of teaching the basics of getting started in ASP.NET. Many books skimp on the things you need before coding can begin, or they leave it out completely. Here you'll find plenty of help and suggestions for using the most modern tools available to a new ASP.NET developer.
This book provides you with the background necessary for building ASP.NET applications. It covers what nearly every introduction book covers, the ASP.NET controls, data access, master pages, and so on. What sets it apart from most other books is how clearly the material is presented to the reader. You won't find some golden piece of information you've never heard before but that's not the focus of the book. For a beginner, it's a perfect choice.
Not long ago I received an email from someone at Packt Publishing asking if I would review their latest ASP.NET book. I gladly accepted as this is something I'd like to do more of. I have another book on my bedside table waiting for a review and I'm in the middle of performing a technical edit of a book due for publication in July. I'm thoroughly enjoying this kind of work and hope to continue it. More on that in a future entry I imagine.
The book is called ASP.NET Data Presentation Controls Essentials. This book is clearly marked as not being for beginners to the ASP.NET framework and I would suggest potential readers follow that warning. The book is littered with helpful snippets of C# code showing you how to obtain data-driven output in your ASP.NET pages. These snippets can be confusing if you're not fairly comfortable with the ASP.NET framework and the event model. There are not that many instances of a full walk-through in the examples provided, so it's hard to follow unless you know what you're doing. I personally found no trouble in keeping up with the book. So, beginners, you've been warned. :)
The author has a clear understanding of the subject matter and it shows in this book. The topics presented cover a solid portion of data access and presentation in ASP.NET. I do wish there had been some introduction to ADO.NET at the very beginning of the book. Being as ADO.NET is the fundamental building block to this book, I think it would have been a welcome addition. The book itself is just over 200 pages that are broken down into 8 chapters. At a $40 list price in the US, that's a hard sell to many in the technology world. A chapter or two in some of the background required for the text could have helped this potential problem for would-be buyers. It will not be a concern to everyone but the technology group is quite sensitive to the "price per page" ratio found in their technical materials.
As a first edition, there are a number of formatting and technical mistakes present in this book. I noticed a specific code example towards the beginning of the book where quotations had been replaced by another character, which certainly would not compile and run for the reader. A reader with C# experience would notice this instantly, but it's a mistake that should have been corrected. The indentation of the code examples in this book are widely varied. As a developer, it's fundamental to see correct formatting in code, and a book should hold that to a higher standard. I also noticed a few instances of code that was simply formatted in such a way that made it invalid. It would not compile if sitting in Visual Studio. Again, something an experience reader would catch easily and wouldn't impede their progress through the book.
Overall, I liked the book. It contains valuable information if you need a lesson in data presentation controls for ASP.NET. If you are considering this book, I would pick it up at your local book store and determine if the content is what you're looking for and whether the list price can be justified to you. Even with the technical mistakes and being a quick read, it will be a worthwhile purchase to many developers looking to understand the data presentation controls available in ASP.NET.
Session state is a very useful tool for an ASP.NET developer. I use the Session object in every project. I use it to store information related to the current user that I need quick access to throughout their visit. It's important not to overuse the Session object but rather to store quick bits of information that need to persist over a single, or multiple, post-backs.
The most painful part of using the Session object built-in to the ASP.NET framework is the error prone nature of getting and setting variables inside of the Session object. The common usage of getting something out of Session looks like this:
Product product = Session["MyProduct"] as Product;
Sure, it's simple enough and makes sense. However, there is the potential to forget the name of the object you'd like to retrieve. Wouldn't it be nice if the Session was a strongly-typed object that wouldn't allow for this mistake?
In various projects I've been using what I call the SessionWrapper. I can't take credit for the name or the idea, as it was something a past co-worker of mine opened my eyes to. However, his implementation was different than mine in that you simply stored the SessionWrapper object itself in Session and accessed it in your pages. The usage looked like this:
SessionWrapper sessionWrapper = Session["SessionWrapper"] as SessionWrapper;
sessionWrapper.Product = new Product();
I wanted to get away from touching the Session object in my presentation code. Why couldn't I simply say:
SessionWrapper.Product = new Product();
With this goal, my implementation of the SessionWrapper was created. The key is using the HttpContext to interact with the Session object while not being required to inherit the Page class. Doing this allows us to access the Session object in a static manner, creating the usage scenario we desire. I've included a full Visual Studio 2008 solution at the bottom of this post. Make sure you check that out. Here's the code for the SessionWrapper class:
using System;
using System.Web;
namespace SessionWrapperExample
{
public static class SessionWrapper
{
public static Product Product
{
get
{
if (null != HttpContext.Current.Session["SessionWrapperProduct"])
return HttpContext.Current.Session["SessionWrapperProduct"] as Product;
else
return null;
}
set
{
HttpContext.Current.Session["SessionWrapperProduct"] = value;
}
}
}
}
Download the Solution: SessionWrapperExample.zip
By now we've nearly all heard of the ASP.NET MVC framework available in CTP form. The Model View Controller architecture has been around for quite some time but more popularly in the desktop world. Java has seen its share of MVC web frameworks over the years and just a few years ago Ruby on Rails crashed the party with its own MVC implementation for a rapid development environment. Once Ruby on Rails hit, all of a sudden MVC was all the rage. It wasn't long before these frameworks became available as extensions for ASP.NET. Microsoft has now joined the party with an official feature due towards the middle of 2008. In the last few weeks the ASP.NET team has shipped a CTP release for feedback and to get people started with the technology. I've looked at it quite a bit myself and I'm loving what I've seen thus far.
There are a number of reasons to be excited about this framework. Some of the biggest are separation of concerns, testability, and performance.
Separation of concerns allows you, the developer, to create self aware components that don't heavily depend on another un-related component to function. Think about removing the logic of your postback event in ASP.NET 2.0. Take that code and move it somewhere more centralized that will be used by similar web views. That concept is the relationship between the Controller and the View. The View should simply display something while the Controller should tell it what to display. The Model describes the data and is used by your Controllers and Views as something I like to think of as a transitional object.
Testability is a major concern with most developers these days. Currently automated unit testing is nearly impossible with the current Web Forms architecture present in ASP.NET. Sure, you can unit test your data and business layers. However, once these layers reach the presentation layer, testing expected behavior just isn't possible in an automated fashion. The ASP.NET MVC framework allows testability through the separation of concerns along with the way a Controller will dictate which View is rendered. That functionality allows for easy testability.
The final reason I'll discuss here is performance. ViewState is a piece of magic all too often by the Web Forms architecture and simply is a bloated method for persisting data across HTTP requests. The ASP.NET MVC framework will remove this dependency and will provide better performing environment for our web applications.
I'm in the planning stages of a new project and really investigated whether I should begin ASP.NET MVC development. Since it's so new I'm not going to risk it but I encourage everyone to keep an eye on this project. I'll definitely be doing that and will be all over a release closer to RTM.
Resources:
ScottGu -
MVC Tag
Phil Haack - ASP.NET MVC PM
More Posts