LINQ
by Steve
Embedded query languages are back. LINQ is a set of extensions for .NET languages (well, C# and Visual Basic) that allows relational-style querying.
This is not a new idea. SQL embedded in Java has been around for years, and SQL in C for decades. It looks like a simple idea that makes things easier for developers. No need to use an API to access the database: just write the query directly in source code. LINQ goes further and introduces some interesting ideas into .NET, such as type-safe results through the use of anonymous classes and the ability to query a very wide range of data types, not just relational stores.
LINQ gives a great deal of power to the developer, and provides an interesting contrast to the Java approach.
Firstly, Microsoft seems to be moving in the direction of language extensions, with C# 3.0 (one of the languages that will provide LINQ) being a dramatic change from earlier versions. Sun has has always been cautious about this approach, preferring to add functionality through an ever-increasing volume of specifications and libraries.
One such specification is for Java persistence and has much of the capability of LINQ (or will have, when the latest version of the specification is finalized), and is called Java Data Objects or JDO. JDO is also store-neutral, with implementations providing persistence to range of types of store, including text files, LDAP, XML, as well as the traditional relational systems.
In its latest version (JDO 2.0), some interesting extensions to previous incarnations of the specification are provided that make JDO somewhat more LINQ-like. One of these is the ability to set the class of the result of a query. In JDO 2.0, queries need not return classes: they can return arbitrary sets of values. One of the options for handling these values is to specify a class with bean properties matching the types of the values. This allows type-safe handling of query results.
In some ways the JDO approach is more flexible than LINQ. In JDO 2.0, query strings, which can be in a range of formats, can be externalized and so can be optimized by a developer or even a DBA as a separate task. Also, the use of external XML mapping data provides a better isolation of the Java code from the database structure. Providing functionality as libraries rather than language extensions ironically makes the Java solution more language-neutral than the .NET approach (.NET traditionally being seen as better designed for multiple languages), as the JDO libraries can be used today from the large number of languages which run on the JVM besides Java.
In some respects the format of the query (language extension or string) should perhaps not be a major concern of the developer in a well-designed approach to persistence. Both LINQ and JDO offer forms of transparent persistence, enabling most of the retrieval and storage of information to be 'behind the scenes' and not require explicit interaction with the data store. When used appropriately JDO requires only minimal querying.
There is one way that LINQ may positively influence persistence standards in Java. It seems that the recommended approach to persistence in Java is going to be JPA (Java Persistence Architecture), a subset of EJB 3.0. Although influenced by JDO, this API seems to be targeted primarily at relational stores. Perhaps the useful flexibility of LINQ, matched by the store-neutrality of JDO, will encourage future versions of JPA to address a wider range of persistence methods.
Embedded query languages are back. LINQ is a set of extensions for .NET languages (well, C# and Visual Basic) that allows relational-style querying.
This is not a new idea. SQL embedded in Java has been around for years, and SQL in C for decades. It looks like a simple idea that makes things easier for developers. No need to use an API to access the database: just write the query directly in source code. LINQ goes further and introduces some interesting ideas into .NET, such as type-safe results through the use of anonymous classes and the ability to query a very wide range of data types, not just relational stores.
LINQ gives a great deal of power to the developer, and provides an interesting contrast to the Java approach.
Firstly, Microsoft seems to be moving in the direction of language extensions, with C# 3.0 (one of the languages that will provide LINQ) being a dramatic change from earlier versions. Sun has has always been cautious about this approach, preferring to add functionality through an ever-increasing volume of specifications and libraries.
One such specification is for Java persistence and has much of the capability of LINQ (or will have, when the latest version of the specification is finalized), and is called Java Data Objects or JDO. JDO is also store-neutral, with implementations providing persistence to range of types of store, including text files, LDAP, XML, as well as the traditional relational systems.
In its latest version (JDO 2.0), some interesting extensions to previous incarnations of the specification are provided that make JDO somewhat more LINQ-like. One of these is the ability to set the class of the result of a query. In JDO 2.0, queries need not return classes: they can return arbitrary sets of values. One of the options for handling these values is to specify a class with bean properties matching the types of the values. This allows type-safe handling of query results.
In some ways the JDO approach is more flexible than LINQ. In JDO 2.0, query strings, which can be in a range of formats, can be externalized and so can be optimized by a developer or even a DBA as a separate task. Also, the use of external XML mapping data provides a better isolation of the Java code from the database structure. Providing functionality as libraries rather than language extensions ironically makes the Java solution more language-neutral than the .NET approach (.NET traditionally being seen as better designed for multiple languages), as the JDO libraries can be used today from the large number of languages which run on the JVM besides Java.
In some respects the format of the query (language extension or string) should perhaps not be a major concern of the developer in a well-designed approach to persistence. Both LINQ and JDO offer forms of transparent persistence, enabling most of the retrieval and storage of information to be 'behind the scenes' and not require explicit interaction with the data store. When used appropriately JDO requires only minimal querying.
There is one way that LINQ may positively influence persistence standards in Java. It seems that the recommended approach to persistence in Java is going to be JPA (Java Persistence Architecture), a subset of EJB 3.0. Although influenced by JDO, this API seems to be targeted primarily at relational stores. Perhaps the useful flexibility of LINQ, matched by the store-neutrality of JDO, will encourage future versions of JPA to address a wider range of persistence methods.