LINQ, que es sobretodo y más que nada un lenguaje de consulta de objetos, tiene varias implementaciones:

1. LINQ to Objects, que permite el filtrado, proyección, join, totalización de colecciones, etc. específicamente con objetos en memoria
2. LINQ to XML, que permite ese mismo tipo de operaciones sobre árboles XML, y además operaciones de creación/actualización/eliminación de nodos en dichos árboles
3. LINQ to SQL, que permite básicamente las mismas operaciones que el anterior pero teniendo como repositorio permanente a una base de datos relacional
4. LINQ to Entities / Entity Framework, parecido al punto anterior pero con un esquema de mapeo entre tablas relacionales y clases O-O bastante más flexible

Es interesante que LINQ to SQL y Entity Framework son muy similares, principales diferencias (desde mi corta experiencia):

1. LINQ to SQL está “más cerca” de la base de datos como consecuencia de lo cual:
1. Hay una relación más clara y menos flexible entre cada tabla y cada clase en C# (o VB.NET o cualquier lenguaje .NET)
2. Genera código de interacción con la base de datos que aprovecha mejor las facilidades del motor, lo que lo hace potencialmente más eficiente
3. Este mismo hecho hace más difícil crear proveedores para LINQ to SQL (hasta hace poco el único adecuadamente robusto era el de SQL Server, provisto por Microsoft por supuesto)
2. Entity Framework está “más cerca” del modelo de objetos del negocio como consecuencia de lo cual: 
1. Se pueden hacer mapeos más sofisticados entre múltiples tablas hacia un solo objeto (y viceversa). Como consecuencia, el conjunto de objetos que manipula la lógica de negocio se “sienten” más naturales
2. Un modelo de proveedores más sencillo y genérico, lo que no permite aprovechar facilidades específicas de los motores, pero hace que sea más probable contar con aplicaciones que cambien fácilmente de motor de base de datos
3. Este mismo hecho, ha hecho que aparezcan más proveedores de Entity Framework (SQL Server, DB2, MySql, Firebird, PostgreSql, entre los que me acuerdo ahora)

Lo extraño es que Oracle se ha mantenido alejado de estas nuevas tecnologías y se ha puesto en modo “sin comentarios” en lo que a proveedores para LINQ to SQL o Entity Framework se refiere. Para mi, esto es cederle espacio a SQL Server, dado que Visual Studio (y por ende .NET Framework) es una plataforma de desarrollo extremadamente popular, así que pienso que si no hay una buena alternativa para usar tecnologías modernas como Entity Framework con Oracle, la gente puede decantarse hacia SQL Server.

Ahora bien, una cosa buena de .NET es que tiene un gran ecosistema de desarrolladores y casas de software, y aquí es donde entra en la historia Devart, una casa de software (de Rusia o Ucrania, no estoy seguro). Ellos han estado trabajando desde hace algún tiempo en un proveedor de Entity Framework para Oracle, que de hecho he usado con Oracle 10g con buenos resultados. La buena noticia es que hace poquito liberaron nuevas versiones de sus proveedores, lo que incluye dotConnect for Oracle 5.00. Más interesante todavía, esta nueva versión incluye un proveedor para LINQ to SQL (lo que se supone que era tan complicado que iba a tomar un buen tiempo antes de que existiera una versión para algo distinto a SQL Server).

Para quienes usan Visual Studio 2008 con Oracle, el proveedor de Entity Framework y LINQ to SQL de Devart es algo que vale la pena probar.