MDX is a very capable and powerful query language that can query multidimensional OLAP data sources like SSAS.
But MDX is not integrated into .NET, meaning you have to write a lot of supporting code to plum parameters and marshal flat ADOMD.NET recordsets into composed graphs of associated .NET objects. MDX is not friendly for IntelliSense, unit testing and refactoring.
MDX is a quite difficult language to master, not that many software developers know it, and those that do most of the time do not know .NET well enough. Because of that MDX queries are often developed by a different developer than the rest of a .NET application, so .NET and MDX developers have to communicate and coordinate.
MDX is quite verbose when it comes to dimensional attribute and measure references specification.
MDX does not support OOP.
Also MDX queries cannot be reused to query data sources that do not support MDX like relational databases or in-memory objects.
LINQ does not have any of the listed drawbacks, but it requires to specify aggregations, groupings, sorting and joins in each query. It complicates LINQ queries, slows down LINQ learning and adoption, query development and testing, making LINQ queries more fragile to design changes. Also LINQ could not be used to query OLAP data sources like SSAS so far.
LINQ/SDX solves both of these problems.
It is built on top of LINQ, so it is integrated into .NET, and like LINQ does not require writing any parameters pluming and results marshalling code; it is friendly for IntelliSense, unit testing and refactoring.
And like MDX, LINQ/SDX does not require to specify aggregations, groupings, sorting and joins in each query. And like MDX it can be used to query OLAP cubes in SSAS.
SSAS Entity Framework Provider (tm) (patent pending) is a component that enables you to use LINQ/SDX together with Microsoft ADO.NET Entity Framework (EF) to query OLAP cubes in SQL Server Analysis Services (SSAS). Because you still use Entity Framework, you do not have to learn new mapping attributes and XML elements in order to marshal flat ADOMD.NET recordsets back into .NET object graphs, if you have already learned how to do that in EF.