Esther Schindler who is the editor of the email newsletter DevSource Update recently wrote about Visual C++ and Microsoft’s LINQ Project that adds the ability to use SQL code directly in VB and C# programs (emphasis mine):
Ever since the PDC, developers and the press have been talking about the LINQ technology that Microsoft showed off. The overwhelming response appears to be positive, and from all I can tell (I haven’t taken the time to read the tech docs) it seems to be justified. But I can’t help it if I see the plot holes in a movie, and it’s my job to ask the questions that everybody is trying not to ask. After all, what we saw at the PDC wasn’t a product. It wasn’t even a technology preview. We (rather gratefully) got a peek at what the Smart Folks at Microsoft are scribbling on their white boards. This is the time to point out any problems — when they can be incorporated into the final design documents.
For instance, I carefully noted that, in all the LINQ demos, nobody so much as mentioned C++. (A Microsoft PR person later told me that each language group sets its own priorities, and the Visual C++ team hasn’t decided yet where LINQ will fit.) Also, everybody has asked programmers about the wondrous capabilities of LINQ; what do the DBAs think? I realize that DBAs and programmers rarely drink at the same bars, but still…!
My response to her concerns about LINQ and Visual C++ is:
You should use the right tool for the right job. Anyone programming databases with C++ is almost certainly using the wrong tool. VB.NET and C# are much better tools for doing database development. Hopefully this is so obvious I don’t have to explain why.
She continued with (emphasis mine):
The larger question, though, is about the much-vaunted ability for a Visual Studio programmer to access databases without knowing SQL or XML particularly well. I’m wary of anything that promises “ease of use” by assuring someone that it’s okay to remain ignorant. I remember, far too well, how the computer industry promised to make computers “idiot-proof.” The result? We now have a lot of idiots using computers. Sometimes, making things simpler _isn’t_ a good idea.
I’m not saying that LINQ is a bad thing. Far from it: I suspect it’s an elegant solution of the “Duh, why didn’t we think of this before?” variety. However, this is the time to raise the uncomfortable questions, and I don’t see very many people doing so.
Uh, as far as I can see, LINQ doesn’t hide SQL or XML, it just gives a much cleaner syntax for accessing that can be syntax checked at compile time. A developer would still need to write SQL and to understand XML. For example, this looks like to me it requires knowing SQL:
Dim custs() As Customer = …
Dim waCusts = Select c.Name, c.City From c In custs Where c.State = “WA”
Did Esther really look at LINQ before writing this editorial? Maybe people aren’t asking the questions because the questions are not relevent?
I’m *so* looking forward to adopting this in our development, but haven’t had much time to look into it myself.
What I’d like to see, however, would be fewer examples of select statements rewritten in C# and some examples of calls to stored procedures.
Making it easier to directly manipulate data using commands native to the language doesn’t, in my opinion, entirely justify mixing the data access in with the rest of the code.
Unless people are really paying attention when they start using it, we’re going to end up with a lot of the same sort of program design as when people first started using SQL with VB or ASP: Naked select statements sprinkled throughout unrelated code.
The fact that the select statement is dressed up all pretty and looks a little more like C# won’t eliminate the need to ensure that your program and your database are well-designed.
I like keeping my SQL and my VB/C# code separate. I like the fact that my stored procedures can limit what the program can do, defining an ‘interface’ that the program and its users must adhere to in order to manipulate data. I like security that keeps the program and/or its users from dropping tables if they’ve found a bug that I haven’t.
What I hope to enjoy from LINQ is a much less painful method of accessing and working with recordsets. I could care less about slapping a dress on T-SQL and calling it C#.
>> What I’d like to see, however, would be fewer examples of select statements rewritten in C# and some examples of calls to stored procedures.
I definitely agree with that!
>> Making it easier to directly manipulate data using commands native to the language doesn’t, in my opinion, entirely justify mixing the data access in with the rest of the code.
Yeah, but if you look more at LINQ, you’ll see they are applying set logic to all data, not just database. For example, you could do a select on an array of objects and return an array. So it is bigger than just SQL databases.
>> I like keeping my SQL and my VB/C# code separate. I like the fact that my stored procedures can limit what the program can do, defining an ‘interface’ that the program and its users must adhere to in order to manipulate data.
I agree, but damn wouldn’t it be nice if they would make SQL stored procedures more object-oriented, or at least more modular? The lack of encapsulation features in SQL is maddening to me.
>> What I hope to enjoy from LINQ is a much less painful method of accessing and working with recordsets. I could care less about slapping a dress on T-SQL and calling it C#.
One of the benefits I see is from LINQ is not much being able to execute a database select natively, but a larger move to integration of languages where you don’t have to build commands for other environments using a string that can’t be syntax checked. For example, I’d love to see the ability to integrate JavaScript into VB.NET for sending to a browser. Who knows, maybe they’ll be doing that with ATLAS.