Jump to content

Linq


Pangloss

Recommended Posts

Just curious if anyone else has messed around with LINQ. It stands for Language Integrated Query, and it's Microsoft's effort to move the SQL language into the programming domain before compile time. One advantage of this is that using Visual Studio 2008 you get after-the-dot methods and usability assistance with your SQL while writing actual programming code.

 

The real advantage of it is that it enables a kind of higher-level organization and management of your data infrastructure. Right now in most n-tier, data-driven business applications you work something like this:

 

- Presentation Tier (theme/skin/css, buttons, grids for display, etc)

- Information Tier (classes containing objects typically populated via ADO code with data acquired with a "data access" class)

- Infrastructure Tier (database stuff: SQL queries, views, stored procedures, functions, etc)

 

The biggest drawback of this approach has always been complexity and usability, which of course means long learning curves. Back in 2004/2005 Microsoft took a kind of "first stab" at improving things by introducing a new design-time object called the "DataSource" (e.g. "SqlDataSource"), which is a parameterized, drag-and-drop toolbox object that the user can configure with Visual Studio properties and/or HTML parameter tags. Then the object compiles it executes code stored in the operating system (in the .NET Framework) which writes the actual data access code (the ADO) on the fly.

 

The drawback of THAT approach is that it didn't support n-tier architectures very well. Great for simple web apps, but not great for enterprise software. Those people ended up ignoring or bypassing the new objects, leaving us back at square one. The LINQ approach supports n-tier architectures, but still allows for relatively easy configuration. It gets people out of ADO code and into designers that are easier to learn and manipulate, which still allowing for enterprise-grade development.

 

I didn't mean this to sound so much like an advertisement for Microsoft, really I'm just trying to spark a little discussion about the future of n-tier business apps, if anyone's interested. :D

Link to comment
Share on other sites

The nice thing is that it's not limited to SQL backed systems, you can use LINQ to run through various datastructures that you are using or implement a few interfaces and have your own datastructure usable (through IQueryable etc I believe).

 

Saying that, the underlying idea isn't completely original, as bascule mentioned previously, things like ActiveRecord and ADO.NET have done similar things (not specifically the query part, but bringing the handling of the data and types into the programming language) but it'll be interesting to use.

 

Personally I'm more interested in them bringing various features that they require for LINQ, such as lambda expressions, and more functional concepts (which LINQ seems to be part of) and so on, to languages such as VB.NET. There are many times when you just want to do something in a functional manner because it is the quickest and most readable way to do something, and a nice fusion of imperative and functional ideas in languages certainly benefits developers.

Edited by Aeternus
Link to comment
Share on other sites

LINQ is an interesting idea, but certainly not a new one.

 

One of the earliest systems I know doing this sort of thing is Erlang. Like other languages such as Python and Haskell, Erlang supports a language construct called a list comprehension, which is basically a declarative way of querying and transforming one or many lists into a single result.

 

Erlang took the extra step of using list comprehensions to perform queries against its database. However, rather than loading the complete contents of one or more database tables into memory in the form of a list, database tables act like "virtual lists" to the list comprehensor. This is accomplished using a technique known as a parse transformation, where the original language syntax you enter is programmatically transformed into something completely different. It's a similar idea to macros in Lisp.

 

This idea inspired an extension to Ruby's ActiveRecord called Ambition, which allows you to work with databases using the same toolset Ruby uses for querying arrays and other array-like data structures (called Enumerable). Ruby's approach to this is generally quite functional, making use of lamba expression-like things (blocks) and higher order functions when describing the desired transformation.

 

I really prefer the above approaches over something like LINQ, as there's no disconnect between how the programmer would normally operate on the language's first class data structures and how they operate on databases. However, LINQ is trying to solve the problem of adding these sort of functional / declarative approaches to languages which don't have them in the first place, and in that regard it's probably done the best job possible.

 

All that said, it's certainly much better than the nightmare which is SQL...

Link to comment
Share on other sites

That's interesting, I will have to read up further on those subjects. I'm still determined to introduce non-Microsoft methods into my Web applications course, although I still have not done so. I have a special topics class I may be teaching in the winter that I may be able to do something along those lines with.

 

That doesn't surprise me about it not being new; Microsoft's strengths lie more in the area of developing ideas than creating them. Lots of cash on hand + thousands of programmers sitting around = something. Of course, whether that something turns out to be useful or not is another question. One of the problems with that approach is that you end up having to continue to support that something forever afterwards. Leads not only to bloat but to complicating the very thing you're trying to simplify -- the learning curve.

 

Anyway, just to expand on the discussion a bit, I went to a meeting of .NET programmers the other day, and we were shown a bit of something that MS plans to introduce into the framework soon called the "Entity Framework". The general idea of it is that you can map your data infrastructure to a set of "entities" (like classes but different) which are mapped out in XML-based form in your application.

 

It seemed to me that basically what they were talking about is replacing the middle tier of a standard n-tier arrangement with this entity framework. It would be more responsive to changes through the use of updating wizards and methods. And you could create "entities" for events as well as tables, so for example you could have an entity that was basically just an SQL query, and then call that query as an object in your code.

 

Just to map that against the LAMP world, based on what Bascule wrote about, it sounds to me a lot like the Ruby ActiveRecord concept, with Ambition taking the role of LINQ. Does that sound about right?

Link to comment
Share on other sites

ActiveRecord is the most popular Object Relational Mapper (ORM) for Ruby. That said, Java probably did the best job popularizing the concept with Hibernate.

 

Googling for ORMs for .NET, there are dozens available. I'm not sure which of them are particularly popular, but this site lists quite a few of them:

 

http://csharp-source.net/open-source/persistence

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.