Работа Linq к объектам по сравнению с ESQL
(добавление ответа, потому что примеров с универсальными символами Generics недостаточно)
// Source
List<Integer> intList = Arrays.asList(1,2,3);
List<Double> doubleList = Arrays.asList(2.78,3.14);
List<Number> numList = Arrays.asList(1,2,2.78,3.14,5);
// Destination
List<Integer> intList2 = new ArrayList<>();
List<Double> doublesList2 = new ArrayList<>();
List<Number> numList2 = new ArrayList<>();
// Works
copyElements1(intList,intList2); // from int to int
copyElements1(doubleList,doublesList2); // from double to double
static <T> void copyElements1(Collection<T> src, Collection<T> dest) {
for(T n : src){
dest.add(n);
}
}
// Let's try to copy intList to its supertype
copyElements1(intList,numList2); // error, method signature just says "T"
// and here the compiler is given
// two types: Integer and Number,
// so which one shall it be?
// PECS to the rescue!
copyElements2(intList,numList2); // possible
// copy Integer (? extends T) to its supertype (Number is super of Integer)
private static <T> void copyElements2(Collection<? extends T> src,
Collection<? super T> dest) {
for(T n : src){
dest.add(n);
}
}
6 ответов
Наиболее очевидные различия:
Linq к Объектам является кодом со строгим контролем типов включая хороший синтаксис понимания запроса. То, что “from” прибывает перед “select”, позволяет IntelliSense помогать Вам.
Объект SQL использует традиционные основанные на строке запросы с более знакомым SQL как синтаксис, куда оператор SELECT прибывает перед ИЗ. Поскольку eSQL является строкой, базирующиеся, динамические запросы могут быть составлены традиционным способом во время выполнения с помощью обработки строк.
менее очевидное основное отличие:
Linq к Объектам позволяет Вам изменять форму или "проектировать" результаты Вашего запроса в любую форму, которой Вы требуете с “select новым {...} Синтаксис ”. Анонимные типы, в новинку для C# 3.0, позволили это.
Проекцией не является возможный Объект использования SQL, поскольку необходимо всегда возвращать ObjectQuery< T>. в некоторых сценариях это - возможное применение ObjectQuery< object> однако необходимо работать вокруг того, что.Select всегда возвращает ObjectQuery< DbDataRecord>. см. код ниже...
ObjectQuery<DbDataRecord> query = DynamicQuery(context,
"Products",
"it.ProductName = 'Chai'",
"it.ProductName, it.QuantityPerUnit");
public static ObjectQuery<DbDataRecord> DynamicQuery(MyContext context, string root, string selection, string projection)
{
ObjectQuery<object> rootQuery = context.CreateQuery<object>(root);
ObjectQuery<object> filteredQuery = rootQuery.Where(selection);
ObjectQuery<DbDataRecord> result = filteredQuery.Select(projection);
return result;
}
существуют другие более тонкие различия, описанные одним из членов команды подробно здесь и здесь .
ESQL может также генерировать некоторый особенно порочный sql. Я должен был отследить проблему с таким запросом, который использовал наследованные классы, и я узнал, что мой изодромно с предварением мало ESQL 4 строк был переведен в 100 000 монстров символов SQL statetement.
Сделал то же самое с Linq, и скомпилированный код был намного более managable, скажем, 20 строк SQL.
Плюс, что упомянули другие люди, Linq является сильно типом, хотя очень раздражающий, чтобы отладить без редактирования и продолжить функцию.
AD
SQL объекта (eSQL) позволяет Вам делать вещи, такие как динамические запросы более легко, чем LINQ к Объектам. Однако, если у Вас нет сценария, который требует eSQL, я не решился бы полагаться на него по LINQ, потому что будет намного более трудно поддержать (например, больше никакого времени компиляции, проверяя, и т.д.).
я полагаю, что LINQ позволяет Вам предварительно компилировать свои запросы также, которые могли бы дать Вам лучшую производительность. Rico Mariani занесенный в блог о производительности LINQ некоторое время назад и обсуждает скомпилированные запросы.
Больше кода, который можно покрыть временем компиляции, проверив на меня, является чем-то, во что я поместил бы более высокую премию, чем производительность. Сказав, что на данном этапе я, вероятно, склонился бы к ESQL не только из-за производительности, но и это также (в настоящее время) намного более гибко в том, что это может сделать. Нет ничего худшего, чем использование технологического стека, который не имеет функции, в которой Вы действительно действительно нуждаетесь.
платформа объекта не поддерживает вещи как пользовательские свойства, пользовательские запросы (для того, когда необходимо действительно настроить производительность), и не функционирует то же как linq-to-sql (т.е. существуют функции, которые просто не работают в платформе объекта).
Мое персональное впечатление от Платформы Объекта - то, что существует большой потенциал, но это, вероятно, немного к "твердому" в, он - реализация для использования в продуктивной среде в ее текущем состоянии.
хороший график, показывающий здесь сравнение производительности: Исследование производительности Entity Framework не большая разница между ESQL и Entities but overall differences significant in using Entities over direct Queries
Entity Framework uses two layers of object mapping (compared to a single layer in LINQ to SQL), and the additional mapping has performance costs. At least in EF version 1, application designers should choose Entity Framework only if the modeling and ORM mapping capabilities can justify that cost.
Для прямых запросов я использую linq для сущностей, для динамических запросов я использую ESQL. Может быть, ответ не «либо / или», но и / также.