Каково различие между выражениями запроса LINQ и дополнительными методами

Вы должны проверить Auth0, я считаю, что это «правильный метод», который вы ищете.

Auth0 является облачной платформой, которая обеспечивает аутентификацию и авторизацию как сервис. Как поставщик аутентификации, Auth0 позволяет разработчикам легко внедрять и настраивать безопасность входа и авторизации.

Зачем использовать Firebase и Auth0 вместе?

Следует отметить, что Firebase предоставляет функции аутентификации из коробки.

Я цитирую:

Вы должны рассмотреть Auth0 с пользовательским токеном Firebase, если вы:

  • Уже реализовали Auth0 и хотите добавить возможности реального времени в ваше приложение
  • Необходимо легко использовать выданные токены для защиты серверной части, не предоставляемой Firebase
  • Необходимо интегрировать поставщиков социальных идентификаторов, помимо Google, Facebook, Twitter и GitHub
  • Необходимость интеграции провайдеров корпоративной идентификации, таких как Active Directory, LDAP, ADFS, SAMLP и т. Д.
  • Требуется настраиваемый процесс аутентификации
  • Требуется надежное управление пользователями с API-интерфейсами и удобной для пользователя панелью управления
  • Хотите иметь возможность динамически обогащать профили пользователей
  • Требуются такие функции, как настраиваемый вход без пароля, многофакторная аутентификация, защита от взлома пароля, обнаружение аномалий и т. д.
  • Должен придерживаться таких нормативных требований, как HIPAA, GDPR, SOC2 и т. Д.
  • Должен придерживаться таких нормативных требований, как HIPAA, GDPR, SOC2 и т. Д.

По сути, базовых поставщиков аутентификации Firebase должно быть достаточно, если у вас очень простое приложение с необходимыми аутентификационными требованиями и вы используете только базы данных Firebase.

Дайте мне знать, если вам нужна дополнительная помощь. А теперь иди и получи отличный день!

14
задан Sander 28 April 2009 в 05:27
поделиться

7 ответов

Обновление: вы исправили свой заголовок, поэтому игнорируйте напыщенную речь.

Название вашего вопроса не имеет ничего общего с примерами кода. Ваш вопрос подразумевает, что один синтаксис IEnumerable, а другой IQueryable, но это неверно. В ваших примерах, если db.Surveys является IQueryable, то оба ваших сэмпла используют IQueryable. Я постараюсь ответить на оба вопроса.

Два ваших примера кода - это просто разные способы написания одинаковых запросов LINQ (при условии, что они написаны хорошо). Код в примере 1 - это просто сокращение для кода в примере 2. Компилятор обрабатывает код в обоих примерах одинаково. Подумайте о том, как компилятор C # будет обрабатывать int? так же, как Nullable . Оба языка C # и VB.Net обеспечивают этот сокращенный синтаксис запроса. Другие языки могут не иметь этот синтаксис, и вам придется использовать пример 2 синтаксиса. Фактически, другие языки могут даже не поддерживать методы расширения или лямбда-выражения, и вам придется использовать еще более уродливый синтаксис.


Обновление:

Чтобы продолжить пример Сандера, когда вы пишете это (синтаксис понимания запроса):

var surveyNames = from s in db.Surveys select s.Name

Вы думаете , что компилятор превращает это сокращение в следующие методы (методы расширения и лямбда-выражения):

IQueryable<string> surveryNames = db.Surveys.Select(s => s.Name);

Но на самом деле методы расширения и лямбда-выражения сами являются сокращением. Компиляторы выдают что-то вроде этого (не совсем, но просто для того, чтобы дать представление):

Expression<Func<Survey, string>> selector = delegate(Survey s) { return s.Name; };
IQueryable<string> surveryNames = Queryable.Select(db.Surveys, selector);

Обратите внимание, что Select () - это просто статический метод в классе Queryable . Если ваш язык .NET не поддерживает синтаксис запросов, лямбда-выражения или методы расширения, это то, как вы должны написать код самостоятельно.


Каковы преимущества использования одного стиля над другим?

Для небольших запросы, методы расширения могут быть более компактными:

var items = source.Where(s => s > 5);

Кроме того, синтаксис метода расширения может быть более гибким, например, условные выражения where:

var items = source.Where(s => s > 5);

if(smallerThanThen)
    items = items.Where(s => s < 10);
if(even)
    items = items.Where(s => (s % 2) == 0);

return items.OrderBy(s => s);

Кроме того, некоторые методы доступны только через синтаксис метода расширения (Count (), Aggregate). (), Take (), Skip (), ToList (), ToArray () и т. Д.), Поэтому, если я воспользуюсь одним из них, я Я обычно напишу весь запрос в этом синтаксисе, чтобы избежать смешивания обоих синтаксисов.

var floridaCount = source.Count(s => s.State == "FL");

var items = source
            .Where(s => s > 5)
            .Skip(5)
            .Take(3)
            .ToList();

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

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


Обновление: вы исправили свой заголовок так что игнорируйте все остальное ...

Теперь о вашем названии: Что касается LINQ, IEnumerable и IQueryable очень похожи. Они оба имеют почти одинаковые методы расширения (Select, Where, Count и т. Д.), С основным (только?) Различием в том, что IEnumerable принимает Func в качестве параметров, а IQueryable принимает Выражение > в качестве параметров. Вы выражаете оба одинаково (обычно выражения lamba), но внутренне они совершенно разные.

IEnumerable является дверью в LINQ to Objects. Методы расширения LINQ to Objects можно вызывать для любого IEnumerable (массивы, списки, все, что можно перебрать с помощью foreach ), а функция Func преобразуется в IL при компиляции время и работает как обычный код метода во время выполнения. Обратите внимание, что некоторые другие поставщики LINQ используют IEnumerable и поэтому на самом деле используют LINQ to Objects (LINQ to XML, LINQ to DataSet).

IQueryable используется LINQ to SQL, LINQ to Entities и другими поставщиками LINQ, которым требуется изучить ваш запрос и перевести его вместо непосредственного выполнения кода. IQueryable запросы и их выражение > не компилируются в IL во время компиляции. Вместо этого создается дерево выражений , которое можно просмотреть во время выполнения. Это позволяет переводить операторы на другие языки запросов (например, T-SQL). Дерево выражений может быть скомпилировано в Func во время выполнения и выполнено при желании.

Пример, иллюстрирующий разницу, можно найти в этом вопросе , где OP хочет выполнить часть запроса LINQ to SQL в SQL Server, приведите объекты в управляемый код и выполните оставшуюся часть запроса в LINQ to Objects. Чтобы добиться этого, все, что ему нужно сделать, это привести IQueryable в IEnumerable, где он хочет, чтобы произошел переход.

Это позволяет переводить операторы на другие языки запросов (например, T-SQL). Дерево выражений может быть скомпилировано в Func во время выполнения и выполнено при желании.

Пример, иллюстрирующий разницу, можно найти в этом вопросе , где OP хочет выполнить часть запроса LINQ to SQL в SQL Server, приведите объекты в управляемый код и выполните оставшуюся часть запроса в LINQ to Objects. Чтобы добиться этого, все, что ему нужно сделать, это привести IQueryable в IEnumerable, где он хочет, чтобы произошел переход.

Это позволяет переводить операторы на другие языки запросов (например, T-SQL). Дерево выражений может быть скомпилировано в Func во время выполнения и выполнено при желании.

Пример, иллюстрирующий разницу, можно найти в этом вопросе , где OP хочет выполнить часть запроса LINQ to SQL в SQL Server, приведите объекты в управляемый код и выполните оставшуюся часть запроса в LINQ to Objects. Чтобы добиться этого, все, что ему нужно сделать, это привести IQueryable в IEnumerable, где он хочет, чтобы произошел переход.

Пример, иллюстрирующий различие, можно найти в этом вопросе , где OP хочет выполнить часть запроса LINQ to SQL в SQL Server, перенести объекты в управляемый код и выполнить остальную часть запрос в LINQ to Objects. Чтобы добиться этого, все, что ему нужно сделать, это привести IQueryable в IEnumerable, где он хочет, чтобы произошел переход.

Пример, иллюстрирующий различие, можно найти в этом вопросе , где OP хочет выполнить часть запроса LINQ to SQL в SQL Server, перенести объекты в управляемый код и выполнить остальную часть запрос в LINQ to Objects. Чтобы добиться этого, все, что ему нужно сделать, это привести IQueryable в IEnumerable, где он хочет, чтобы произошел переход.

23
ответ дан 1 December 2019 в 08:17
поделиться

LINQ - модное слово для технологии.

IQueryable - это интерфейс .NET, который используется LINQ.

В отличие от стиля, между ними нет никакой разницы. Используйте любой стиль, который вы предпочитаете.

Я предпочитаю первый стиль для длинных выражений (например, тот, что показан здесь) и второй для очень коротких выражений.

4
ответ дан 1 December 2019 в 08:17
поделиться

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

Когда вы пишете это:

var surveyNames = from s in db.Surveys select s.Name;

Компилятор преобразует это в:

IQueryable<string> surveryNames = db.Surveys.Select(s => s.Name);

Действительно, я думаю, что выражения запросов были просто созданы по маркетинговым соображениям - языковая конструкция, похожая на SQL, которая будет привлекать внимание при разработке LINQ, а не та, которая предлагает много фактического использования. Я считаю, что большинство людей просто используют методы расширения напрямую, так как они приводят к более унифицированному стилю кодирования, а не к смеси C # и SQL.

2
ответ дан 1 December 2019 в 08:17
поделиться

Предложение where в первом примере на самом деле является просто синтаксическим сахаром для предложения Where во втором методе. Фактически, вы можете написать свой собственный класс, который не имеет ничего общего с Linq или IQueryable, и, просто имея метод Where, вы можете использовать этот синтаксический сахар. Например:

    public class MyClass
    {

        public MyClass Where<T>(Func<MyClass, T> predicate)
        {
            return new MyClass { StringProp = "Hello World" };
        }

        public MyClass Select<T>(Func<MyClass, T> predicate)
        {
            return new MyClass ();
        }



        public string StringProp { get; set; }
    }

Это, очевидно, глупый пример, но обратите внимание, что есть метод Where, который просто возвращает новый MyClass с stringprop, установленным в Hello World. Для демонстрации:

MyClass a = new MyClass();
            var q = from p in a
                    where p.StringProp == "foo" // doesnt matter what we put here, as we're not really checking the predicate
                    select p;
            Console.WriteLine(q.StringProp);

Это приведет к написанию «Hello World». Опять же, этот пример явно бессмыслен, но он доказывает, что синтаксис «где» просто ищет метод Where в вашем коде, который принимает Func.

2
ответ дан 1 December 2019 в 08:17
поделиться

1. / Название вашего вопроса не соответствует тому, что вы задали.
2. / Название вашего вопроса на самом деле не имеет смысла. Linq расшифровывается как Language Integrated Query и является общим термином для множества технологий и практик, IQueryable - это интерфейс, который обычно используется для облегчения Linq. вы сравниваете яблоки и апельсины
3. / Что касается вашего фактического вопроса, главное отличие - это стиль, для сложных запросов, подобных этому, мое личное предпочтение - вторая версия, так как она четко показывает прогрессию наборов результатов.

1
ответ дан 1 December 2019 в 08:17
поделиться

Ваш Sample1 является представлением Linq верхнего уровня, он более читабелен и при компиляции преобразуется в дерево выражений, т.е. в ваш Sample2 .

var x = from s in db.Surveys
    join sq in db.Survey_Questions on s.ID equals sq.Survey_ID
    join q in db.Questions on sq.Question_ID equals q.ID
    join qg in db.Question_Groups on q.ID equals qg.Question_ID
    where s.Type_ID.Equals(typeID) & s.Type.Equals(type)
    select new { question = sq.Question, status = sq.Status, grp = qg };

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

var exp=x.Expression;

Выражения используются, когда запрос менее сложен.

1
ответ дан 1 December 2019 в 08:17
поделиться

Я думаю, ваш вопрос лучше сформулировать так: «В чем разница между IEnumerable и IQueryable по отношению к LINQ»

LINQ-запросы по умолчанию возвращают IQueryable . IQueryable позволяет вам добавлять другие фильтры или «предложения» к вашему запросу перед его выполнением.

Ваш запрос LINQ (первый пример) и ваш LINQ с использованием цепочки методов (второй пример) дают одинаковый результат с разным синтаксисом ,

Можно написать запрос LINQ в виде цепочки методов LINQ и наоборот. Это действительно зависит от ваших предпочтений.

@Lucas: IEnumerable отличается тем, что выполняет запросы в памяти и IQueryable делает нехватку памяти. То есть, когда вы находитесь в итераторе foreach , вы используете IEnumerable, и когда вы строите свой запрос, либо с помощью методов расширения, либо с помощью LINQ из o в synatax объекта , вы построение IQueryable . IQueryable выполняется, как только вы касаетесь перечислителя.

0
ответ дан 1 December 2019 в 08:17
поделиться
Другие вопросы по тегам:

Похожие вопросы: