TwitterDevs is a social networking site where developers interested in Twitter hang out.

Generally, LINQ queries instead of stored procs are fine for normal code; SQL Server caches execution plans regardless of whether its a LINQ query or stored proc. That way, you have strongly typed queries that are part of your source control system and maintained like all your other code. Every once in a while, there are still scenarios that make me believe a stored proc would be a better solution.  Most notably, whenever I have more complex logic than an insert, update, or delete, it seems easier to perrform the operation via stored proc. For example, what if I need to work with multiple tables in the same algorithm. Using LINQ queries means that everything must be in a transaction in code (i.e. TransactionScope) and you will have multiple queries to the database. This introduces more complexity, multiple moving parts, and is slower. On the other hand, putting all of that logic into a single stored proc, including the transaction, makes the code easier to work with.  While I like consistency; doing everything the same way as much as possible; a little common sense tells me that an occasional exception to the rule can make code more maintainable and perform better. To be clear about my approach: I use LINQ queries as a normal part of development and will introduce a stored proc only when it makes more sense to do so.

Now that I have the last chapter of LINQ Programming written, I can start updating the C# Tutorial with more C# 3.0 content.  Today, I updated Lesson 10: Properties. My primary focus was to add a new section for auto-implemented properties but I did much more than that.  I re-wrote all of the example code, meaning that I needed to add extensive updates to text also.  This was an eye-opening experience because looking back at when I first created this particular lesson, 2/10/2001, there is a dramatic change in writing style.  Anyway, the most important change, besides adding auto-implemented properties, is that the examples are based on manipulating a Customer object, instead of a SomeProperty object. I think that putting the example in a more familiar context is helpful and consistent with feedback I've received over time. I'll probably take the same approach when updating other tutorials, but I'll see what people think first.

Received a comment by a collegue the other day about some code I had written; He said it was "Upside Down". Here's something that's structurally similar:

 

 

I'm just using a couple new C# 3.0 features, object-initializers and lambdas. The generics and ForEach are from C# and .NET 2.0.  It's certainly different from C# 1.0, but I wouldn't say there's anything wrong with writing code like this. Reading from the top down, it says take this List of string and iterate through it, applying this function to each item.  What's your opinion?

Imagine you're working on an ASP.NET page that hosts a wizard with multiple steps and each step of the wizard has multiple inputs.  To ensure the wizard works, you must start the site, possibly navigating through log in and other paths to get to where you are, and then step through the wizard.  Sure, you can set a specific page as the start page and figure out how to bypass login during development, but sometimes you must perform some type of initialization, such as selecting an order, before you can logically use the page you're working on.  Stepping through the wizard, filling in each field, is tedious.  Often, you'll encounter a bug, which is when the real fun <being sarcastic> begins.  Imagine how many trips through the wizard you must take to get to where the bug is to test the work being done.  The reality is that you are spending more time navigating the web site than performing the test.  Again, there are ways to minimize this and it doesn't always happen, but it does happen often enough that it can eat up a lot of time.

 

My favorite solution, that keeps me out of this quandry in the first place, is to write unit tests - just plain old C# code that instantantiates an object, calls a method, and checks the return values to see if the results are what was expected.  If you've separated your business logic  (I like to put it in a DLL), you can test the methods on that object.  VS2008 Pro ships with unit testing built-in (which I use - thank you MS) and there are numerous other unit test automation tools available, many for free. It takes a simple click or two to run the test as opposed to the laborious process described in the previous paragraph.  If you haven't written a test for your current condition, then write the test to reproduce the problem and then debug from running the test.  Unit testing saves me and my team so much time that it seems crazy to code solutions any other way.