Синтаксис запросов LINQ — недооцененный инструмент для разработчиков C#

лично мне уже приходится намного сильнее напрягать мозг, чтобы разобраться что же это за p, c, и что вообще здесь происходит

Для решения этой проблемы не нужно менять синтаксис. Поменяйте названия переменных ( p=>product, c=>category).

Более того, в сложных запросах типа Join с 4-5 аргументами, можно прописывать названия аргументов. Будет у вас что-то вроде

var result = products
    .Where(product => product.Price > 50) 
    .Join(categories, 
          outerKeySelector: product => product.CategoryId, 
          innerKeySelector: category => category.Id, 
          resultSelector: (product, category) => new { 
            ProductName = product.Name,
            CategoryName = category.Name,
            Price = product.Price 
          });

, только красиво подсвеченное в VS.

Скажу честно, я как правило тяготею к цепочке методов... Но только пока дело не доходит до джойнов. Особенно навроде left join-ов (хотя и inner join-ы тоже удобней в query syntax писать). В методном варианте это выглядит как-то уж совсем громоздко и неочевидно...

Как многие уже наверняка знают, LINQ - встроенный в C# язык запросов, которые появился аж в 2007 году (.NET Framework 3.5) и существует он в виде двух реализаций: Query-синтаксис (синтаксис запросов) и Method-синтаксис (синтаксис методов).

Несмотря на все возможности и достоинства синтаксиса запросов, он часто несправедливо игнорируется в пользу синтаксиса методов. 

В принципе в первом предложении ответ на вопрос из второго, почему он сейчас игнорируется. Потому что с 2007 года были добавлены более эффективные иснструменты, которые умеют все тоже, только обладают больше функциональностью и универсальностью, в том числе асинхронными вызовами.

Ну и для начинающих программистов, не особо знакомых с лямбда выражениями, Query синтаксис пониматься будет нааамного проще.

Ну и это тоже железный аргумент. Вместо того, чтобы учиться современным инструментам, вникать в делегаты, анонимные методы и операторы, лучше конечно работать с тем, чем проще.

После группировки для фильтрации можно и не отходить от Query Syntax:

var filteredGroups = 
    from product in products
    join category in categories on product.CategoryId equals category.Id
    group product by category.Name into productGroup
    select new
    {
        CategoryName = productGroup.Key,
        AveragePrice = productGroup.Average(p => p.Price)
    } into s
    where s.AveragePrice > 100
    select s;

Для простых запросов Method-синтаксис удобнее. Просто привыкнуть надо к лямбдам и вообще не шарахаться от чего-то сложнее foreach.)
Когда мне не хватало - пытался Query-синтаксис, получалось лучше, но это НЕ читабельно (мое мнение) и НЕ оптимально. Не хватает Method? EF разрешает в SQL, а дальше и до SP недалеко.
Если нужен Query - что-то в архитектуре вашего ПО не так явно.

У синтаксиса в стиле Query, на мой взгляд, самый большой недостаток это его похожесть на SQL. Эта похожесть путает тех кто знает SQL. Помечтаю немного, но было бы круто если бы Query синтаксис хотя бы для простых конструкций полностью совпадал бы с sql.

Добрый день, я только недавно начал изучать EF и прекрасно понимаю что скорее всего я чего-то не понял в статье, по этому прошу объяснить в чем я не прав.

я так понимаю что для сложного запроса класс Product из простого запроса был модифицирован в

class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    public int CategoryId { get; set; }
}

Мои скромные познания заключаются в том что анонимные типы очень неудобны в дальнейшей разработке и я стараюсь их избегать если это возможно, по этому я бы модифицировал класс Product вот так:

class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    public int CategoryId { get; set; }
    public Category Category { get; set; }
}

при этом свойство CategoryId может быть создано самим EF как shadow property и удалено из класса, если оно используется только для связи таблиц

Для приведенного выше случая существует намного более удобный LINQ запрос и хотелось бы узнать преимущества Query-синтаксиса

var result = products
    .Include(p => p.Category)
    .Where(p => p.Price > 50);

P. S. Или хотелось бы узнать почему в приведенных в статье примерах класс Product не может иметь свойство Category