First Looks

On the State of VS and .NET

Q&A with Richard Hale.

• By Patrick Meader
• 10/01/2008

VSM: The combination of C# 3.0 and .NET 3.5 has been available for a while. Now that you've had some months to kick the tires officially, what has made the strongest lasting impression of this combo for you?

RHS: With C# 3.0, the language gets more expressive, and it's easier to get more done with less effort. Overall, the features in C# 3.0 are terrific. Many of these features exist because of the need to support LINQ, but they are still nice features to have. For example, extension methods are a huge win for developers.

Richard Hale Shaw, founder of Richard Hale Shaw Group and a conference chair at 1105Media Inc.'s VSLive!

.NET 3.5, and the LINQ API in particular, is also a big win. The LINQ model and the LINQ API are nice features, as are LINQ to Objects. But the particular LINQ providers, that's where things are a little different because it depends on how that LINQ provider was implemented.

LINQ to SQL is executed well on the whole, as long as you can keep it in context. For example, someone might say: LINQ to SQL doesn't make it easy to put in an abstraction layer for mapping between my database types versus my business types. It's not really designed to do that. That's more for the Entity Framework or NHibernate. At the same time, the Entity Framework is using LINQ to SQL to do this kind of stuff. If you need to do that kind of mapping, then you can look in that direction. But LINQ to SQL, in and of itself, is great at doing what it does. I think it's a much better choice than raw ADO.NET. With the exception of some occasional performance areas, which you need to measure yourself in terms of how you use it, I think LINQ to SQL is far preferable to classic ADO.NET using a DataReader. I can't see a good reason to continue to invest in DataSets or Typed DataSets, compared to LINQ to SQL. And compared to the complexity of using a DataReader (and its lack of type-safety -- which means its lack of database schema knowledge), LINQ to SQL is a huge win, although there are a couple cases where the performance of a DataReader is a little better.

VSM: Tell me why you think some of the other providers don't succeed as well as LINQ to SQL does.

RHS: Take the case of LINQ to XML. If you need only to navigate the structure of any XML document, LINQ to XML is just fine. It has some definite advantages over XmlReader. But if you need a typesafe way of getting to your data in a given XML document, I don't think LINQ to XML is there.

What's really needed is LINQ to XSD, a way to apply LINQ to the schema of a given XML document, not the underlying elements, attributes, and structural entities. There's a preview technology called LINQ to XSD that's being worked on by Microsoft. I think it will be great once it's out; it's definitely the right way to go. Consider the difference between LINQ to SQL and LINQ to XML. LINQ to SQL uses code generation. You point LINQ to SQL at a given database and its schema, and Visual Studio or SQLMetal or whatever is going to do some code generation. So you've got a typesafe mechanism for addressing the contents of that schema and navigating through the data, per se. And that's what LINQ to XSD is going to do for you. LINQ to XML by itself just doesn't do that. I think that's what a good LINQ provider needs to do -- capture the type safety aspect because we want to work with the content.

VSM: What is the most significant challenge you see .NET developers facing today?

RHS: One of the most significant challenges is sorting out the best way to solve a particular problem or set of problems. It's not just best practices, but when you should use a particular approach or technique versus another one. We had this problem in a similar way in the late 1990s, with the alphabet soup of data access methods we got from Microsoft between roughly 1995 and 2000. For example, we had DAO, RDO, ADO, ODBC, and OLEDB -- it was endless -- and now we're almost on a parallel path today.

VSM: Can you elaborate on these similarities, please?

RHS: We have core ADO.NET, and we've got some improvements in terms of type safety in ADO.NET 2.0, especially with data sets. But then we've also got LINQ and LINQ to SQL in particular, which in many respects is a vast improvement over ADO.NET 2.0, although raw ADO.NET is a little bit better in many respects if you're squeezing out performance. But in terms of reusability, LINQ to SQL is probably better. You've also got the Entity Framework if you need to create an abstraction layer between your database schema and your domain objects and map them.

Similarly, we've got technologies like Windows Communication Foundation (WCF) that came out a year and a half ago that are really now starting to get some traction. But the question for a developer who is new to services or is doing new development with services is this: At what point should developers be investing in WCF versus .NET Remoting or traditional ASMX Web services? Or, if they are new to this altogether, what technologies should they be adopting? I think there's just a lot of confusion on these points.

The point is that knowing which technology to apply and when is critical. Sorting that kind of thing is out is definitely something that developers need to address. VSM

Be sure to read the second half of this interview in the November 2008 issue of Visual Studio Magazine.

Richard Hale Shaw is the founder of Richard Hale Shaw Group, and has consulted, mentored, and trained professional software developers since 1993. He's an articulate writer and speaker on topics dear to the hearts of software developers, and an outspoken critic of broken developer tools. Shaw specializes in advanced .NET development and C#, and currently focuses on WCF, C# 3.0, and LINQ. He's a member of Microsoft's C# Customer Council and has been a Visual C# MVP since 2004. You can reach him at www.RichardHaleShawGroup.com.