Здравствуйте, Коваленко Дмитрий, Вы писали:

КД><далее — изделия советских инженеров?>
КД>3. BLT — ваще рулит. Правда на днях я на него ругался, когда пытался запустить Януса на FB. Траблы с квотированными именами. Проблему я ниасилил.

+1 к "ваще рулит". У нас это "продакшн библиотека", наподобие "Си" в языках прог-я: делает ровно то, что скажут и никаких внутренних выкрутасов. Единственная беда — доставание сгенерённого ID для PK, но мы просто прикрутили функцию (исходники открыты и более-менее понятны). Т.к. FireBird не особо распространён, подозреваю, его не особо тестировали, но т.к. исходники доступны, вполне можно вылечить. Да и на форуме есть разработчик.
Я бы рекомендовал именно BLToolkit, т.к. не люблю "развесистых" решений, а BLT прост как молоток.

Не так давно вновь ковырялся и с EF, и c NHibernate. Определённо, NHibernate тоже стал лучше, но я там не нашёл, как mapp'ить на хранимые процедуры. По мне это из самых полезных features в EF, поскольку таким способом можно использовать ORM без существенных потерь производительности по сравнению с чистым SQL.

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

>>>Я с линком писал такие запросы, что вручную их почти нереально было родить. И эти запросы проверялись при компиляции.
__>>Чушь. Ну напишите мне что я "нереально не могу родить" с помощью T-SQL или PL/SQL, что вы можете сделать с помощью LINQ.
Y>Начнём с совcем классики. E2, так сказать:
Y>

 db.Table.Where(t => (filter1 == null || t.Field1 == filter1) && (filter2 == null || t.Field2 == filter2)  && (filter3 == null || t.Field3 == filter3));

Y>Incorrect syntax near ') динамический sql не предлагать.
А как вам такой вариант? Используется Razor. При этом есть метод CheckAllQueries, который полностью автоматически находит все запросы в сборке, перебирает все варианты параметров и отправляет запросы на SQL сервер в режиме SchemaOnly.

        void Example1(int? filter1, DateTime? filter2, Option<string> filter3)
        {
            var infos = Query<IInfo>.New(new {filter1, filter2, filter3}, @"
SELECT  *
FROM    [Table]
WHERE   1 = 1
@if (filter1.HasValue) {
        @:AND Field1 = @filter1
}
@if (filter2.HasValue) {
        @:AND Field2 = @filter2
}
@if (filter3.HasValue) {
        @:AND Field3 = @filter3
}").List();
        }

    interface IInfo
    {
        Guid Id { get; }
        int? Field1 { get; }
        DateTime? Field2 { get; }
        string Field3 { get; }
    }

Есть даже метод FindUsages(tableName, columnName = null). Пример результата его вызова:

C:\...\Source\ControllableQuery.Demo\SomeClass1.cs (Ln 15)
C:\...\Source\ControllableQuery.Demo\SomeClass2.cs (Ln 27)
C:\...\Source\ControllableQuery.Demo\SomeClass2.cs (Ln 103)

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

AP>А как вам такой вариант? Используется Razor.

Я чего-то не заметил или теперь и на сервере имеем бессмертное

If @filter1 Is Not Null 
         Set @SQLQuery = @SQLQuery + ' And (Field1 = @filter1) '

Зато sql у нас генерит не EF/L2S/BL а Razor. Теперь заживём!

А в чём профит этой затеи?

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

I>Не так давно вновь ковырялся и с EF, и c NHibernate. Определённо, NHibernate тоже стал лучше, но я там не нашёл, как mapp'ить на хранимые процедуры. По мне это из самых полезных features в EF, поскольку таким способом можно использовать ORM без существенных потерь производительности по сравнению с чистым SQL.

Чтобы "использовать ORM без существенных потерь производительности по сравнению с чистым SQL" нужно правильно писать проекции и делать хорошие индексы.

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

AP>Здравствуйте, Yoriсk, Вы писали:

AP>А как вам такой вариант? Используется Razor. При этом есть метод CheckAllQueries, который полностью автоматически находит все запросы в сборке, перебирает все варианты параметров и отправляет запросы на SQL сервер в режиме SchemaOnly.

Сила Linq в динамической композиции запроса без склейки строк. То что ты предлагаешь все равно склейка строк, которая очень быстро становится неподдерживаемой.
Я уверен что при появлении Roslyn в широких массах такие "активные строки" с проверкой при компиляции будут частым явлением, но вряд ли смогут быть применении в сколь-нибудь сложных случаях.
Кроме того EntityFramework теперь умеет делать миграции, что делает его в 100500 раз круче любого ORM.

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

G>Кроме того EntityFramework теперь умеет делать миграции, что делает его в 100500 раз круче любого ORM.

О да, это совершенно в духе Microsoft: библиотека делает всё, но всё делает одинаково хреново. Ни уникальных (чего уж о фильтрованных) индексов, ни Unique Constraint'ов. Про что-то отличное от SQL Server.

И "киллер-фича": нет поддержки MSBuild (про migrate.exe знаю, и это костыль).

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

QL>

QL>The EF code base has a long history, going back to the WinFS days, with parts of the code base being 10+ years old. [...] EF7 will be a lightweight and extensible version of Entity Framework that just pulls forward the commonly used features. In addition, we’ll be able to include some commonly requested features that would have been difficult to implement in the existing code base, but can be included from the start in EF7.

QL>http://blogs.msdn.com/b/adonet/archive/2014/05/19/ef7-new-platforms-new-data-stores.aspx

Да уж, "эту песню не задушишь не убъешь!" (с)
Самое время вспомнить краткую историю EF — давным давно, в далекой-далекой галактике, во времена первых бэтт .Net 1.0 стартовал амбициозный проект под названием ObjectSpaces. Новому языку и экосистеме обязательно же нужен самый лучший на свете ORM? И эти могучие ребята обещали наконец показать всему миру, как нужно работать с БД. Суровые были архитекторы — во всех других ORM-ах был фатальный недостаток — его делали не они.
Долго ли, котротко ли, но ко времени выхода .Net 2 — стали появляться первые публичные сборки, но тут что-то пошло не так и проект прикрыли...
Однако, в это время стартовал проект WinFS, в рамках ОС Longhorn. А объектной файловой системе, конечно же нужен самый лучший ORM! И команда ObjecrSpaces в полном составе мигрирует на новый проект. Конечно же они сразу обнаруживают фатальный недостаток в текущей реализации — ее делали не они.
Долго ли коротко ли, но что-то пошло не так и проект прикрыли...
Тем временем подоспел С# 3.0, и LINQ, и команда компилятора шарпа, примерно за год, реализовала LINQ2SQL с лямбдами и выводом типов.
Но нельзя же оставаться .Net-у без лучшего на свете ORM-а? И команда ObjectSpaces практически полным составом начинает делать EF. Очевидно, во всех существующих системах был фатальный недостаток — его делали не они.
LINQ2SQL пошел в продакшн, получил заслуженную славу, пролез в кучу проектов и стал готовиться второй релиз, а команда ObjectSpaces все так же перепиливала ObjectSpaces под EF.
Когда проекту под названием EF стукнуло 5 лет, LINQ2SQL уже пару лет был в продакшене и стало понятно, что тянуть с релизом больше нельзя — на свет появился EF 4.0 (редкостно сырой был продукт, откровенно говоря). С более низкого номера версии стартовать было попросту не прилично... И им бы до сих пор никто не пользовался, если бы не случилось страшное.
Команде компилятора как-то не по статусу заниматься тулами для работы с БД, когда на фичи языка ресурсов не хватает, и LINQ2SQL попытались передать команде сиквела, но те отпинались и, в конце-концов, LINQ2SQL прибился в горячие объятия команды EF где и был похоронен, так как обладал фатальным недостатком — его писали не они. (и не кого не волновало, что L2S до сих пор эффективнее и удобнее, чем все что писалось командой EF за последний десяток лет)
И вот, к шестой версии EF стало понятно, что что-то пошло не так...
Ждем продолжения истории? =)

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

Здравствуйте, Нахлобуч, Вы писали:

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

G>>Кроме того EntityFramework теперь умеет делать миграции, что делает его в 100500 раз круче любого ORM.

Н>О да, это совершенно в духе Microsoft: библиотека делает всё, но всё делает одинаково хреново. Ни уникальных (чего уж о фильтрованных) индексов, ни Unique Constraint'ов. Про что-то отличное от SQL Server.
И что? Все равно всем ОРМам надо как минимум повторит фичи ef.

Н>И "киллер-фича": нет поддержки MSBuild (про migrate.exe знаю, и это костыль).
А зачем тебе поддержка msbuild? Initializer накатит обновление базы при старте.

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

IB>Очевидно, команда ObjectSpaces обладает фантастическим даром убеждения. Я не могу придумать других причин — как можно продавать одну и ту же откровенно ущербную идею, и выпускать на ее основе кривые и не рабочие продукты больше десятка лет, и все еще получать финансирование на реализацию своих заблуждений.

Я вот наблюдаю похожий процесс 4 года. Архитект команды в почти 30 человек адски харизматичный лидер с очень низкой грамотностью, но хорошо прокачан в баззвордах и умеет писать шикарные proof-of-concept, ни разу не занимался ни серьезным багфиксом ни майнтенансом, основной метод борьбы с проблемами — переписывание с нуля. Рефакторинг проекта в его исполнение может остановить проект на срок от недели до полутора месяцев. Когда включает свой рупор, у команды выключается мозг, любые идеи воспринимаются на ура.

Начиналось с сервелата, "всё есть сервелат". Потом появилась самопальная либа T, и лозунг поменялся "Все есть Т". Далее появился HTML5 и лозунг стал "всё есть HTML5". Потом появился клиенцкая либа О и лозунг стал "всё есть О". Потом появился клиенцко серверный Б и лозунг "Всё есть Б".

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

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

Щас товарищ добрался до процессов. Разумеется, все процессы оказались неправильными. Теперь с проектами задвигается новый процесс: "МДД — mock(merge) driven development". Судя по всему, продукт-овнеры тоже ведутся на его зомбирование, несмотря на очевидные проблемы с их проектом — писали-писали год, в продакшн не вышли, начали переписывать заново.

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

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

IB>Очевидно, команда ObjectSpaces обладает фантастическим даром убеждения. Я не могу придумать других причин — как можно продавать одну и ту же откровенно ущербную идею, и выпускать на ее основе кривые и не рабочие продукты больше десятка лет, и все еще получать финансирование на реализацию своих заблуждений.

А ты давно пробовал использовать ef на практике? После допила migrtions и передачи в OpenSource версия 6.0 получилась очень достойная.

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

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

G>И что? Все равно всем ОРМам надо как минимум повторит фичи ef.

Нет. ORM ортогонален миграциям, и наличие последних в первом никакой особенной ценности EF'у как ORM'у не добавляют. А по поводу фич -- NHibernate далеко впереди.

G>А зачем тебе поддержка msbuild? Initializer накатит обновление базы при старте.

Ну здрасти приехали. Т.е. вместо того, чтобы этим занимался, грубо говоря, CI-сервер (который имеет всю полноту информации для того, чтобы откатить потенциально неудачный деплоймент), мы перекладываем ответственность на приложение? И даем ему права DDL Admin'а? Мне кажется, это, мягко говоря, несколько неправильно.

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

Y>Я чего-то не заметил или теперь и на сервере имеем бессмертное
Y>

Y>If @filter1 Is Not Null 
Y>         Set @SQLQuery = @SQLQuery + ' And (Field1 = @filter1) '
Y>

Y>Зато sql у нас генерит не EF/L2S/BL а Razor. Теперь заживём!
Не совсем понял о чем вы. В СУБД уходят уже прошедшие через Razor строки. Razor используется только как замена StringBuilder-а с кратким синтаксисом.

Y>А в чём профит этой затеи?
Автоматическая проверка всех динамических запросов. Получили фактически то, зачем делался LINQ для баз данных. И при этом работаем с нативным SQL. Для удобной склейки строк используем Razor.

При работе с СУБД изначальная задача так и стоит – сгенерировать строку запроса (плюс коллекцию параметров). Вот и решили ее прозрачным образом. Фактически решили проблемы, связанные с прямым использованием SqlCommand/DataReader, и не добавили своих в отличие от LINQ.

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

G>А ты давно пробовал использовать ef на практике? После допила migrtions и передачи в OpenSource версия 6.0 получилась очень достойная.

У нас пяток продуктов используют EF. Там плохо всё. Начиная с того, что товарищи пытаются влиять на схему БД (патамушта если сделать правильно, то EF не смогёт), и кончая сгенерированным SQL'ем; этот газенваген словами не живописать.

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

G>Сила Linq в динамической композиции запроса без склейки строк.
Это его слабость. Склейка строк рулит. Просто раньше приходилось склейку строк покрывать тестами, сейчас тесты делаются автоматически.

G> То что ты предлагаешь все равно склейка строк, которая очень быстро становится неподдерживаемой.
Выше предложено склейка строк с автоматической проверкой. Утверждение о "неподдерживаемой" голословная чушь.

G>Кроме того EntityFramework теперь умеет делать миграции, что делает его в 100500 раз круче любого ORM.
Ты думаешь, не у кого не было миграции до этого? В нормальных командах это уже давно решено. Это должно просто быть. Странно это выдавать за мега фичу.

Здравствуйте, Нахлобуч, Вы писали:

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

G>>И что? Все равно всем ОРМам надо как минимум повторит фичи ef.

Н>Нет. ORM ортогонален миграциям, и наличие последних в первом никакой особенной ценности EF'у как ORM'у не добавляют.
Еще как добавляют, тупо скорость разработки. Создать БД руками, а потом сгенерировать модель и обвесить аннотациями в разы медленнее, чем просто написать код модели и включить миграции. Про обновление бд и модели молчу.
Все разработчики, кроме совсем упоротых, начав использовать миграции хрен с них соскочат.

Н>А по поводу фич -- NHibernate далеко впереди.
Да ладно? Напомни когда в NHibernate появились:
1) Асинхронное выполнение запросов, чтобы await работало
2) Готовая функция или расширение вроде https://github.com/loresoft/EntityFramework.Extended, которые позволяют делать массовые обновления и удаления
3) Локальный кеш в виде ObservableCollection для того чтобы байндить сеты напрямую в UI, а не писать 100500 мапперов

G>>А зачем тебе поддержка msbuild? Initializer накатит обновление базы при старте.

Н>Ну здрасти приехали. Т.е. вместо того, чтобы этим занимался, грубо говоря, CI-сервер (который имеет всю полноту информации для того, чтобы откатить потенциально неудачный деплоймент), мы перекладываем ответственность на приложение?
CI сервер не решает проблем рассинхрона моедли и приложения. А миграции, как ни удивительно, решают.

Н>И даем ему права DDL Admin'а? Мне кажется, это, мягко говоря, несколько неправильно.
Почему это неправильно? В 90% случаев применения ORM в БД никто кроме приложения не ходит, так что вполне нормальный сценарий.
А если у тебя Data Warehouse, куда ходят много приложений, то туда с ORM обычно никто не лезет, да и логика реализована внутри базы, что является проблемой для ORM.

Хотя и в этом случае EF рулит, он позволяет использовать себя как чистый маппер, отображает результаты запросов на объекты.

Буквально пару лет назад ничего этого в ef не было, с тех пор много поменялось.

Здравствуйте, Нахлобуч, Вы писали:

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

G>>А ты давно пробовал использовать ef на практике? После допила migrtions и передачи в OpenSource версия 6.0 получилась очень достойная.

Н>У нас пяток продуктов используют EF. Там плохо всё. Начиная с того, что товарищи пытаются влиять на схему БД (патамушта если сделать правильно, то EF не смогёт), и кончая сгенерированным SQL'ем; этот газенваген словами не живописать.
Че-то ты путаешь. В EF6 схему можно сделать любую. Если билдера не хватит, то просто напиши DDL команды руками. Скорее всего ты говоришь EF4, где схема генерится по модели и влиять но это нельзя.


По поводу генерированного SQL — обычно решается выкидыванием репозитариев, протаскиванием IQueryable на уровень контроллеров, добавлением проекций в выборки, потом созданием индексов по результатам запроса к missed indexes и все начинает летать. Есть конечно особо запущенные случаи, когда в базе накрутили дохрена всего, что ef не может это прожевать, но в этих случаях вообще ни один ORM прожевать не сможет.

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

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

G>>Сила Linq в динамической композиции запроса без склейки строк.
AP>Это его слабость. Склейка строк рулит. Просто раньше приходилось склейку строк покрывать тестами, сейчас тесты делаются автоматически.
Конечно рулит, а автоматизированная (безопасная) склейка строк, которую дает Linq рулит втройне. Ты с чем пытаешь спорить?

G>> То что ты предлагаешь все равно склейка строк, которая очень быстро становится неподдерживаемой.
AP>Выше предложено склейка строк с автоматической проверкой. Утверждение о "неподдерживаемой" голословная чушь.
Ну не начинай, ты уже в этой теме отличился. Можем повторить:

IQueryabl<Customer> GoldCutomer(this IQueryable<Customer> source, decimal threshold)
{
    return source.Where(c => c.Orders.Sum(o => o.OrderDetails.Sum(line => line.Quantity*line.Price))>thershold);
}

Форма запроса на входе (source) неизвестна, так может быть как выборка по ключу, так и запрос всех кастомеров, купивших за последние 3 дня.
На выходе надо получить только тех, кто купил более чем на указанную сумму.

Покажи как это сделать склейкой строк.


G>>Кроме того EntityFramework теперь умеет делать миграции, что делает его в 100500 раз круче любого ORM.
AP>Ты думаешь, не у кого не было миграции до этого? В нормальных командах это уже давно решено. Это должно просто быть. Странно это выдавать за мега фичу.
В каких нормальных командах? Приведи хоть пару ссылок.

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

R>Выскажите пожалуйста свои мнения!
Стандартный use case такой, работает почти во всех случаях.
Если начинаешь новый проект, то используешь EntityFramework, чтобы быстро начать и запустить проект.
Потом, когда проект уже работает, то ты смотришь и оптимизируешь отдельные части, в которых у тебя есть проблем с производительностью.

Если у тебя проект масштаба StackOverflow, то заменяешь EF на какой-нибудь Dapper и производишь другие оптимизации в архитектуре.

Извините, я сейчас в совсем другой предметной области, а с БД имел плотное общение примерно в 2000-2001. С тех пор нормально помню SQL, без изысков, но что такое outer join помню хорошо.

Я как-то отстал от жизни, зачем пользоваться ORM вообще?

Я пробовал пользоваться ORM в Django и RoR и "как-то не пошлО". С момента написания запросов из хотя бы пары селектов (select from select), или тот же outer join, SQL просто удобнее.