Здравствуйте, IT, Вы писали:

IT>>>Добро пожаловать в мир BLToolkit
A>>Я не думаю, что ты действительно нуждаешься в моём объяснении разницы между table, temporary table и table variable.
IT>Надеюсь тебе не надо объяснять как в приведённмо выше коде заменить слово CREATE на DECLARE?

Осталось только убедиться, что это будет работать

Здравствуйте, IT, Вы писали:

IT>... не позволяет вводить абстракции ...
а какие абстракции позволяет вводить LINQ?

Здравствуйте, Alexander Polyakov, Вы писали:

IT>>... не позволяет вводить абстракции ...
AP>а какие абстракции позволяет вводить LINQ?

C# умеет. Ну и Linq как следствие. Например, можно абстрагироваться от деталей конкретной СУБД.

Здравствуйте, IT, Вы писали:

IT>C# умеет. Ну и Linq как следствие.
LINQ это лишь подмножество C#-а, поэтому то что умеет C# не обязательно умеет LINQ. Поэтому никакого прямого следствия нет, и требуется доказательство -- примеры абстракций; их я у тебя и запросил.

IT>Например, можно абстрагироваться от деталей конкретной СУБД.
Ааа, это. Такие абстракции нам и даром не нужны . Нам существенно лучше без них.
Вообще, если каждую обертку называть словом “абстракция”, то это просто издевательство над понятием “абстракция”.

Здравствуйте, Alexander Polyakov, Вы писали:

IT>>C# умеет. Ну и Linq как следствие.
AP>LINQ это лишь подмножество C#-а, поэтому то что умеет C# не обязательно умеет LINQ. Поэтому никакого прямого следствия нет, и требуется доказательство -- примеры абстракций; их я у тебя и запросил.

Сам додумался или где-то прочитал?
Вообще-то Linq это уже сама по себе абстракция. Позволяет в определённом смысле абстрагироваться от типа источника данных.

IT>>Например, можно абстрагироваться от деталей конкретной СУБД.
AP>Ааа, это. Такие абстракции нам и даром не нужны . Нам существенно лучше без них.
AP>Вообще, если каждую обертку называть словом “абстракция”, то это просто издевательство над понятием “абстракция”.

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

Если же ты беспокоишься об эффективности сгенерированного SQL, то опять же это не проблема Linq в целом, это проблема конкретных реализаций.

Здравствуйте, divergo, Вы писали:

D>Навеяно опросом

Автор: Shmj
Дата: 06.03.11
Вопрос: Язык SQL не очень удобен для написания логики. Но иногда полезно писать основную логику приложения в триггерах и хранимых процедурах для сокращения передаваемых данных (между базой и приложением). Как вы решаете данную проблему?

и рабочей ситуацией.
D>Есть задача перевода на Linq приложения построенного на основе датасетов, хранимых процедур и представлений.
Хранимые процедуры должны умереть (в 99% случаев) — это вообще не вопрос.

А вот чем и как их заменять — можно пообсуждать.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Alexander Polyakov, Вы писали:

IT>>>C# умеет. Ну и Linq как следствие.
AP>>LINQ это лишь подмножество C#-а, поэтому то что умеет C# не обязательно умеет LINQ. Поэтому никакого прямого следствия нет, и требуется доказательство -- примеры абстракций; их я у тебя и запросил.

IT>Сам додумался или где-то прочитал?
IT>Вообще-то Linq это уже сама по себе абстракция. Позволяет в определённом смысле абстрагироваться от типа источника данных.

IT>>>Например, можно абстрагироваться от деталей конкретной СУБД.
AP>>Ааа, это. Такие абстракции нам и даром не нужны . Нам существенно лучше без них.
AP>>Вообще, если каждую обертку называть словом “абстракция”, то это просто издевательство над понятием “абстракция”.

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

IT>Если же ты беспокоишься об эффективности сгенерированного SQL, то опять же это не проблема Linq в целом, это проблема конкретных реализаций.

Больше примеров полезных абстракций мы так и не дождемся?

В твоем последнем посте пошла чистая вода из евангелистических опусов (я это уже всё читал).

Здравствуйте, IT, Вы писали:

IT>Под катом небольшой хелпер для DbManager:

А что, провайдеры (или что там отвечает за абстракцию от кнкретной БД) не умеют по информации о типе возвращать строку с описанием типа?
Или нет готового метода, который по филду создаст строку с декларацией этого филда?
Это пока ещё небыло нужно в тулките или каждый раз приходится вручную делать?

Здравствуйте, Alexander Polyakov, Вы писали:

AP>Больше примеров полезных абстракций мы так и не дождемся?

Да без проблем. Нужно только прояснить один вопрос — что в твоём понимании означает "полезных"? Иначе этот разговор ни о чём, все примеры будут относится к категории бесполезных и непонятно зачем тогда вообще тратить время.

AP>В твоем последнем посте пошла чистая вода из евангелистических опусов (я это уже всё читал).

Задача евангелистов — ликвидация безграмотности. Раз уж меня записали в евангелисты, то, если хочешь, могу продемонстрировать несколько примеров, в которых запросы на Linq просты и понятны, а получающийся SQL уже не так очевиден.

Здравствуйте, IT, Вы писали:

Из профессионального любопытства: как будет выглядеть выборка из параметризуемой функции?

Здравствуйте, _FRED_, Вы писали:

_FR>Это пока ещё небыло нужно в тулките или каждый раз приходится вручную делать?

Не нужно было. Вручную делать приходилось ровно один раз.

Здравствуйте, adontz, Вы писали:

A>Из профессионального любопытства: как будет выглядеть выборка из параметризуемой функции?

Лучше сразу напиши SQL, а я тебе тогда Linq.

Здравствуйте, IT, Вы писали:

IT>Лучше сразу напиши SQL, а я тебе тогда Linq.

Есть функция GetCustomers, которая возвращает записи о клиентах на конкретный момент времени (активен/пассивен, тариф, активная ли скидка, другие зависящие от момента времени параметры)

CREATE FUNCTION [GetCustomers](
    @Timestamp DATETIME2)
RETURN TABLE
WITH SCHEMABINDING
AS
RETURN
(
    ...
)

Запрос не очень тяжёлый (большинство таблиц не большие), но содержащий кучу джойнов. Практика показала, что от выделения его в функцию производительность если и пострадала, то незаметно. А вот жить стало легче. Функция используется в куче разных мест. Возьмём простейший фильтрующий запрос

SELECT
    *
FROM
    [GetCustomers](@Timestamp)
WHERE
    [LastName] LIKE '%кач%'

Интересует как аналогичная сиутация выглядит в Linq любой модификации.

Здравствуйте, adontz, Вы писали:

A>SELECT
A>    *
A>FROM
A>    [GetCustomers](@Timestamp)
A>WHERE
A>    [LastName] LIKE '%кач%'

A>Интересует как аналогичная сиутация выглядит в Linq любой модификации.

Linq 2 SQL умеет генерировать обёртки для таких функций. Для BLToolkit пока нужно описывать их руками. Результирующий код будет таким:

var q =
    from c in GetCustomers(timestamp)
    where c.LastName.Contains("кач")
    select c;

Здравствуйте, IT, Вы писали:

IT>Повторюсь ещё раз. Всё это не недостаток Linq в целом. Это недостатки конкретных реализаций Linq-провайдеров.


у Linq2SQL помнится проблема была с left join, их там просто нет, либо есть но с ограничениями. И какие еще есть реализации линк-провайдеров?

Здравствуйте, IT, Вы писали:

IT>... могу продемонстрировать несколько примеров, в которых запросы на Linq просты и понятны, а получающийся SQL уже не так очевиден.
Это уже похоже на что-то интересное, только фразу “а получающийся SQL уже не так очевиден” надо заменить на “а на SQL человек не сможет записать этот запрос в понятной и очевидной форме”. Если в такой формулировке, тогда, да, продемонстрируй, будет интересно. Человеком, записывающим запрос на SQL, буду я.

Здравствуйте, Sshur, Вы писали:

S>у Linq2SQL помнится проблема была с left join, их там просто нет, либо есть но с ограничениями. И какие еще есть реализации линк-провайдеров?

Всё там есть. Другое дело, что это тот самый случай, когда выразительность Linq не на высоте. Вот LEFT JOIN:

from p in db.Product
join c in db.Category on p.CategoryID equals c.CategoryID into g
from c in g.DefaultIfEmpty()
select new
{
    c.CategoryName,
    p.ProductName
};

Некоторые Linq-провайдеры вводят свои методы LeftJoin, кажется DataObjects это точно умеет. Можно их заменять ассоциациями. Например, приведённый выше пример при соответствующем объявлении ассоциации эквивалентен следующему:

from p in db.Product
select new
{
    p.Category.CategoryName,
    p.ProductName
};

BLToolkit по объявлению ассоциации определяет какой Join использовать. Насчёт Linq 2 SQL не уверен.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Sshur, Вы писали:

S>>у Linq2SQL помнится проблема была с left join, их там просто нет, либо есть но с ограничениями. И какие еще есть реализации линк-провайдеров?

IT>Всё там есть. Другое дело, что это тот самый случай, когда выразительность Linq не на высоте. Вот LEFT JOIN:

Update ... from ...?

Есть ли возможность написать пусть даже простой update без перетаскивания всех строк на клиента? У меня в проекте с линк2sql на каждый update стоит db.ExecuteCommand("UPDATE...");

Здравствуйте, IT, Вы писали:

IT>Некоторые Linq-провайдеры вводят свои методы LeftJoin, кажется DataObjects это точно умеет.
Ха-ха, дополнительными методами проблема LEFT JOIN-ов нормально не решается. На самом деле, если начать копать проблему LEFT JOIN-ов, то оказывается, что она залегает ух как глубоко, и ее хорошее решение куча всего затронет (скорее всего, сам язык C#). А создатели LINQ всё это тупо замели под ковер, заставляя пользователей мучаться с этим “мелким” недостатком.

Если интересно могу расписать подробнее что там с LEFT JOIN-ами, но это не выйдет кратко.

Здравствуйте, Alexander Polyakov, Вы писали:

AP>Если интересно могу расписать подробнее что там с LEFT JOIN-ами, но это не выйдет кратко.

Мне интересно.