DDJ: An area that I've had the opportunity to personally spend some time with is DLINQ, which seems to have come a long ways.
AS: The biggest thing we've done in this most recent CTP is included a graphical designer. This is going to make working with the DLINQ API much easier instead of working with the SQLMetal command-line code generation tool [ Editors note: SQLMetal is described in this early DLINQ document]. With the graphical designer, you just add DLINQ objects with the Add Item template, and you can just drag tables from the server explorer onto the designer surface. That automatically generates all of the DLINQ objects that you need.
DDJ: One of the things that I noticed is that the code that gets generated is an order of magnitude smaller than what's generated for a Typed Dataset. It's really just generating business objects, decorated with some attributes, which map to the table definitions.
AS: Right. Exactly. And then the DLINQ runtime comes along when you execute the query and translates it to SQL to get whatever information you want from your database.
DDJ: There's one thing that I really liked about the DLINQ, and I don't know a better way to put it than to say that it just really felt right when using it.
AS: Ok...
DDJ: Right now when you're working with database, you have Typed Datasets, and Table Adapters, so you have a somewhat strongly typed experience. But then when you get data into your application and you want to do BindingSource, or you want to call the DataTable's Select method, at that point it's all loosely typed. You're specifying column names as strings, it's not checked at compile time. One of the things that I like about DLINQ is that if you have a result set in memory, and you want to filter it down to something like just the customers in Washington, you just throw a Select statement against it. You get full Intellisense. It's compile-time validated. You're not making a copy of the data, you're just getting references to those objects back. It just feels good to use.
AS: It goes back to what we were discussing when we were talking about XML a minute ago. What the user really wants is compile time syntax checking, compile time schema checking, and Intellisense to guide them through the query that they're writing or the XML that they're writing. That's what you get with DLINQ. The other thing is that basically with LINQ, getting back to the whole crux of the project, you have the same code, or the same programmatic construct, for querying against database, XML, or objects. So the query that you would write against SQL with DLINQ would be written the same as a query against a collection of processes or files in the file system.
DDJ: That's what I meant about it just feeling right. A Select statement just feels like the right way to get a subset of information, so whether it's a set of files in a directory, or processes in memory, or anything like that, it has an elegant feel to it. The Intellisense and the strongly typed nature make it really nice to work with.
AS: Now that you have this way to query data within the object space, I think that people will approach program writing differently.
DDJ: Right.
AS: I don't know if we talked about this last time, but I had some interns last summer, and I was trying to get them to implement a project with Datasets and all of that stuff. Their whole approach to the project, even before we sat down to design it, was search. They already fundamentally understood how to query. In the current environment with computers, everyone is search based as part of their daily operations. When you add it to the programming language I think you'll find that new programmers think in terms of search and query pretty naturally.
DDJ: I agree. I think it does map to the real-life experience of how people work. Even non-programmers now innately understand the concepts of search, filter, and sort. They're using those concepts on a daily basis.
AS: Take something like Outlook. There are a lot of Outlook users who are not programmers, but they can create views of their data to help extract information. When you add those constructs to the programming language, it's not a far leap to think that pretty soon we could be expressing those filters in terms of VB code. And then people can modify it if they're not satisfied with what was generated by the visual tool.
