+4  A: 

In some cases, a duplicate way of performing certain tasks is available because they further abstracted it in a subsequent version. Think about the WebClient class which I believe was introduced in .Net 2.0. It basically wraps a lot of the common tasks you used to have to do with several different classes (HttpWebRequest, HttpWebResponse, StreamReader, etc). The old classes are obviously still there if you need to do things a little differently, and for backward compatibility, but if all you need to do is download a resource from the web as a string, you've got WebClient.DownloadString.

Also, you're usually using .Net because you're not splitting hairs over cpu cycles, so the solution with the least amount of code is the preferred method if you're not concerned with performance. If you're programming a server task where no user is going to be "waiting" on a process and you need to open one file and read it into a string, go with the static method that lets you do the whole thing in one line.

Rich
This is good because it gives an explanation to how you would choose in most scenarios e.g. go for the least code wherever possible. I guess for this to be useful, the community would maybe describe scenarios in their experience where the simplest didn't cut it and how they selected a better way.
J M
+1  A: 

I suppose a fairly obvious example would be string concatenation.

When concatenating just a handful of strings, you may as well just use the + operator or String.Concat. More than that and you should really consider using StringBuilder for performance reasons.

Is that the kind of thing you're thinking of?

Ian Nelson
This is a classic example of what I mean. However, I'm worried that this could become a repeat "best practices" question. That worry made me hesitate quite a bit before posting it. I'm very interested in scenarios that aren't covered by the majority of best practice lists if there are any.....
J M
+2  A: 

If you're looking for some of the "why"s in print, you might pick up Bill Wagner's recent More Effective C#.

Dan
+1 thanks for this - maybe I shoud change this to actually be a list of books and links that discuss the why's - that sounds like it would be more useful
J M
+1  A: 

One example that took a while for me to straighten out was the different means of executing code asynchonously. There are BackgroundWorkers, Delegate.BeginInvoke/EndInvoke, and manual thread manipulation. In that case I've found that using Delegates is a good balance of ease of implementation and control; however using manual threads buys you extra control wihtout too much more work--but there is the tradeoff that creating new threads (as opposed to using the recycled ones in the threadpool) is an additional overhead.

STW
This is great. I was just reading about this topic a couple of days ago and trying to determin how to choose between using an asynchronous e.g. BeginRead or calling the synchronous method aysnchronously via a delegate. My thought was the asynchronous method seem to have extra checks as have been provided because those checka are required? But that's as far as I've got with it.
J M
Methods that are named "Begin...Async" and return an IAsyncResult are most often wrappers which handle the delegate manipulation for you. One important tip: If you call Begin...Async then you should *always* call the corresponding End... method. If the async method (on a worker thread) returns a value or raises an exception then your main thread will not be notified until calling End... if you never call end then the background thread is never freed since it hasn't notified you of its result
STW
btw, below is the MSDN article regarding working with delegates--it also applies largely to working with Begin...Async/End... methods. You might want to read-up on the proper practices for using that IAsyncResult object, if you only execute a given method asyncronously once then it isn't terribly important but it is still a significant part of the model.http://msdn.microsoft.com/en-us/library/2e08f6yc%28VS.80%29.aspx
STW