I usually enjoy MS Press titles, but this one was miserable. Other reviewers have mentioned the plethora of shoddy, uncompilable code, so I won't bother to mention any examples. It is worth noting, I suppose, that the VB.NET examples are in somewhat better shape than the C# examples because the authors apparently wrote their examples in VB.NET, but translated to C# without ever compiling, much less testing, their translation. How such a terrible mess could have slipped out the MS-Press door is quite beyond me.If you are technically astute and comfortable with C#, you can probably debug your way through the sample code and derive some benefit from the book. But then we get to area where this book falls down completely: the authors seem to be completely clueless with regard to sound software design. As a service to readers, let me offer some insights into where the book misses the mark so that your code will not similarly go astray:
1. The authors describe abstract classes and interfaces, but do not describe why you would use one or the other. Of course, the key differentiator that the authors miss is that an abstract class can include default implementations of methods. Here's a rule of thumb: if derived classes can piggyback on an implementation of a common base method or methods, put the common code in an abstract class. Otherwise, use an interface.
2. The authors explain that you cannot derive a web form from another web form (i.e., there is no visual inheritance). This is true enough, but many shops, including my customers when I was an MS consultant, plus the one where I now work, use a Page-derived base class from which all page classes inherit. This allows you to provide common functionality across all the pages in your site.
3. On page 157, the authors would have us iterate through a RadioButtonList, check each one to see if it is checked, then perform some operation if it is. This is just dumb. A radio button list can have only one checked member, and it can be accessed by calling RadioButtonList.SelectedItem (or SelectedIndex or SelectedValue, depending on your situation).
4. On page 200, the page class sets stores "true" in ViewState["Changed"] in the TextBox_TextChanged event handler, then checks the value of ViewState["Changed"] in the butExit_Click event handler. Again, the code works, but it's really dumb. Both event handlers will get fired in the same postback, so you ought to give the class that implements the Page a boolean member variable with a default false value. When the TextChanged event fires, set the member variable to true. Then use the member variable in the butExit_Click method. Using ViewState in this situation is kind of like sending a package to your next-door neighbor via Fedex, rather than walking over and ringing his door bell.
5. On p. 254, the authors recommend instantiating a single database connection in global.asax and making it available for each user connection by setting a session variable in the Session_Start event handler. Supposedly, this design "conserves resources and makes it easier to maintain connection and adapter settings...." In fact, what this will do is make your web site scale miserably because every single user will have to wait in line while the others take turns sharing that single connection. **I cannot emphasize enough how bad this design is.**
Windows servers have built in connection-pooling capabilities that do a great job of conserving resources while providing good scalability. Just instantiate a new connection for every database operation, and allow the Windows infrastructure to do its magic behind the scenes. And if you're smart, you'll do this in a class (or classes) in a distinctive logical tier that most designers call the data access layer. However, the three-tier (later n-tier) design revolution that swept through the Windows software world starting about 6 years ago seems to have completely escaped the notice of our authors.
6. On p. 261, the authors use a typed dataset with a type name of dsContacts. They also have a member variable with the name of dsContacts. Does anyone else see the potential for confusion here?
7. On p. 385, the authors recommend using user name as the primary key for a user table. The problems this database design will cause are severe.
* When the second "John Smith" or "Mary Jones" tries to access your system, you'll get a database error. The only workaround is to get John or Mary to use a different name. Yeah, right.
* Using a long string as a foreign key on other tables that reference the user table leads to inefficient space utilization and terrible performance when you do joins.
Anybody who knows anything about database design knows that you set up some kind of guaranteed unique key, such as an auto-increment integer, and make name an attribute of the user.
8. The authors fail to note that if session state uses the sqlserver mode, session state will survive a reset when web.config is changed, so users will not be adversely affected.
9. On p. 408, the authors ignore the security implications of causing an authentication cookie to be written to a user's hard drive. This is a recipe for disaster for users who are accessing a web app from a public location (library, kiosk, Kinko's, etc.) because subsequent users will have access to their credentials by virtue of the authentication cookie already on the hard drive. Do your users a favor and set the createPersistentCookie parameter to false when you call RedirectFromLoginPage().
I could write a much lengthier list of "really dumb coding ideas" to accompany this list of really dumb design ideas, but space does not permit. So let me conclude by stating what should by now be obvious: if you have extensive experience with object-oriented web programming in a multi-tier design paradigm, but simply lack exposure to ASP.NET syntax, you can probably find something useful in this book. Otherwise, stay away!
