Entity Framework vs. LINQ como ORM

LINQ inició siendo una teconología que servía tanto para consultar objetos en memoria, como para mapear tablas de bases de datos SQL a objetos de memoria. Así que luego de hacer el mapeo, con nuestro mismo lenguaje de programación sin necesidad de escribir comandos SQL a través de LINQ tendríamos la posibilidad de hacer consultas y manipulaciones sobre estas entidades en memoria sin mucho problema.

Visto esto, observamos que con LINQ tenemos dos alcances: Como lenguaje de consultas integrado y como ORM.

LINQ fue primero que EntityFramework; al principio LINQ "quizo" ser el ORM de Microsoft, pero demostró algunas deficiencias en ciertos aspectos como la conexión a distintos repositorios. Luego vino el EntityFramework a mejorar esas cosas en las que LINQ tenía debilidades. Pero OJO! EntityFramework solo se ocupa de las operaciones de un ORM. Y el hecho de que haya aparecido, no significa la desaparición de LINQ, dado que LINQ aparte de tener esas caractarísticas de ORM, es un potente lenguaje de consultas integrado que permite consultar tanto entidades (como las arrojadas por EntityFramework, el mismo LINQ o cualquier otro ORM), como objetos personalizados, XML, ActiveDirectory y en general cualquier estructura de datos .NET en memoria que implementen IQueryable (https://msdn.microsoft.com/en-us/library/bb546158.aspx)

En últimas, yo recomendaría usar EntityFramework para hacer ORM y luego usar LINQ para ejecutar consultas muy sencillamente sobre las entidades generadas por el ORM. (Y sobre cualquier otra colección de datos).