Archive For February 2010
ASP.NET MVC v. Web Forms Debate - My View
calendar_today 22 February 2010 21:53
It seems that the whole world (and Margate) is having its say on which is better - MVC or Web Forms. Scott Guthrie posted his views on technical debates in general, and then contributed his thoughts on MVC v. Web Forms. Ian Cooper has an interesting contribution to make to the debate too. Rob Conery (formerly of Microsoft) posted probably the most linked to opinion on the matter. (There - I've just added another link...) A lot of other blog posts around scream that MVC is better because its better. One even tries to posit the notion that some kind of score card approach can help you decide.
ASP.NET MVC is not all about Linq to SQL
calendar_today 21 February 2010 08:21
Pretty much every sample application that illustrates ASP.NET MVC uses Linq To SQL or the Entity Framework as the data access method. I've seen a number of questions posted to the forums at www.asp.net asking if there are any alternatives, and indeed there are. This article will look at using plain ADO.NET within a data access layer to provide dynamic content to a typical small CRUD application.
Using gacutil.exe and Reflection to generate the Exceptions Cheat Sheet
calendar_today 10 February 2010 07:28
The most recent addition to my Cheat Sheets features details of all the Exceptions that can be found in the most commonly used assemblies within ASP.NET development. Compiling this information was an interesting challenge. I could have simply copy-pasted from MSDN, but that would have been extremely tedious. Instead, I ended up with a blend of Linq to XML, Reflection, a dash of Regex and the Global Assembly Cache Tool - gacutil.exe. Here's the full story.
Cheat Sheet - .NET Framework Exceptions
calendar_today 07 February 2010 17:19
Here's a list of Exceptions that can be found in the assemblies which are most commonly used in ASP.NET development. Ideally, you should be as specific as possible when catching or throwing Exceptions. The more specific you are, the less work the CLR has to do in locating the appropriate catch block, and the more informative your error messages are, which should help speed up identifying the source of any problems.