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

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

G>>Продолжай верить, это путь к успеху.
IB>Хочешь померяться успехами?
Прости, но успехи в чтении пресс-релизов меня не интересуют.

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

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

G>>Об этом, видимо, знает лишь "несколько людей" (с)

AVK>Кому интересно, тот знает. Этот функционал еще с BLT, со времен когда одата называлась WCF Data Services.

Приведи пример чтоли... Гугл не нашел.

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

G>Приведи пример чтоли... Гугл не нашел.

http://blogs.rsdn.ru/it/3909654

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

AK>>Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте?
А>Проект в котором важна скорость обработки данных в СУБД. Избавится от использования хранимых процедур в таких проектах невозможно, иначе придется большие объемы данных тащить в приложение и потом обратно с базой их "джойнить", это всегда эффективнее делать на уровне СУБД.

Насколько я помню, EntityFramework не гоняет данные туда-сюда без нужды. Оно генерирует SQL-запрос и все данные обрабатываются на стороне сервера, т.е. из C# кода вы можете делать с данными почти тоже самое, что и через прямой SQL.
Пересылать данные на сторону сервера приложений оно начинает только тогда, когда Вы эти данные вытаскиваете из IQueryable и начинаете обрабатывать построчно C# кодом. Но это уже вполне логично, это уже выходит за рамки SQL-кода вообще и хранимых процедур в частности.

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

G>>Продолжай верить, это путь к успеху.
IB>Хочешь померяться успехами?

Господа не надо. Тут приличный форум.

AK>... мне уже приходилось писать подобие юнит-тестов для EF, где использовалась временная база данных на реальном SQL-сервере. Это работает, но медленно.
Насколько медленно, в миллисекундах сколько и на что тратится?

Н>... и не собрать в одном месте все доводы против EF'а и ORM'ов, подкрепив это все для верности верфицируемыми доказательствами (вот про этот разнесчастный left join, пол неотключаемый LL, что там еще)? ...
Далеко не все вопросы программирования имеют решения в таком ключе, в котором ты ожидаешь. Вот, например, есть две технологии WebForms и ASP.NET MVC. Если начать рассматривать частные случаи, то обе технологии с ними справятся с приемлемым качеством. Но за деревьями не увидишь леса. Сейчас ни один вменяемый разработчик не начнет проект на WebForms.

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

Н>>... и не собрать в одном месте все доводы против EF'а и ORM'ов, подкрепив это все для верности верфицируемыми доказательствами (вот про этот разнесчастный left join, пол неотключаемый LL, что там еще)? ...
AP>Далеко не все вопросы программирования имеют решения в таком ключе, в котором ты ожидаешь. Вот, например, есть две технологии WebForms и ASP.NET MVC. Если начать рассматривать частные случаи, то обе технологии с ними справятся с приемлемым качеством. Но за деревьями не увидишь леса. Сейчас ни один вменяемый разработчик не начнет проект на WebForms.

Ты удивишься, но некоторые вещи на WebForms делаются гораздо быстрее, чем на MVC.
Например такая задача:
1) Есть страница, на ней два списка. В первом есть элементы, второй пуст.
2) Есть кнопки, которые переносят элементы из первого во второй и наоборот.
3) Есть кнопка, по нажатию на которую пользователь попадает на вторую страницу, на которой выводятся элементы во втором списке.
На формах делается за 15 минут максимум.

Это не абстракная задача, это может пригодиться для создания WebUI для проведения тестов.

Конечно для публичных сайтов WebForms не подходит катострофически, а для корпоративного формошлепства в вебе — вполне. Но веб-формы очень сложны, крайне мало людей умеют их готовить правильно.

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

G>Ты удивишься, но некоторые вещи на WebForms делаются гораздо быстрее, чем на MVC.

Только лишь за счет того, что для данной задачи контролы лежат в Toolbar студии. И скорее всего (для интранета) нет особых требований к UI/UX.
Если на примете есть js-конторл такого же типа, то и на MVC это задачка такая же по времени.

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

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

G>>Ты удивишься, но некоторые вещи на WebForms делаются гораздо быстрее, чем на MVC.

Doc>Только лишь за счет того, что для данной задачи контролы лежат в Toolbar студии. И скорее всего (для интранета) нет особых требований к UI/UX.
Так есть, сила WebForms в контролах с готовым поведением (как клиентским, так и серверным) и имитацией состояния. Хотя во многих случаях это не сила, а слабость.


Doc>Если на примете есть js-конторл такого же типа, то и на MVC это задачка такая же по времени.
Обычный select и button.

Если логика требуется на сервере (расчет результатов теста например), то js контролы не сильно помогут, много кода будет написано чтобы передать-получить данные и увязать их с контролами.

AK>трудности написания юнит-тестов для хранимых процедур
можно подумать есть принципиальная разница между тестированием ХП и кода на шарпе

AK>Сейчас на legacy-проекте есть полтора разработчика, которые хорошо ориентируются в имеющихся SQL-процедурах
Прекрасная новость, как мне кажется

AK> а для остальных (и меня в том числе) любое исправление логики в SQL выливается как минимум в час раскуривания, "а как же оно работает". Размеры хранимых процедур достигают нескольких сотен строк, внутри там бывает десяток JOIN'ов, CROSS APPLY и прочих премудростей, которые при беглом прочтении кода понять трудно.
Не хотите читать чужой код, не хватает квалификации для чтения SQLя — обычное явление


AK>Какие ещё минусы есть у Entity Framework? Что может послужить аргументом для отказа от его использования в проекте?
Минусы в использовании практически любой подобной хрени всегда одни и те же
— слой хранимок/вьюх это слой абстракции отделяющий физическую структуру данных от интерфейса. При наличии dev-DBA он необходим
— слой хранимок/вьюх в разы упрощает обеспечение data integrity
— реализация BL вне хранимок создает лишний трафик, из-за передачи данных из сервера БД
— реализация BL вне хранимок часто категорически неприемлема, если сервер БД _может_ находиться далеко (например издыхание сервера БД в основном ДЦ, и автоматический фэйловер к резервному, до которого пинг 70мс, азуры, амазоны, просто фиговый коннект в корпоративном интранете)

Отсутствие поддержки CTE, temporary tables и прочих идиом SQLя — не принципиальны, пока есть возможность обратиться напрямую запросом

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

G>Если логика требуется на сервере (расчет результатов теста например), то js контролы не сильно помогут, много кода будет написано чтобы передать-получить данные и увязать их с контролами.

Да не так уж и много. Json уже вполне хорошо отдается/парсится. Несколько большее чем для готовых контролов, это да. А вот объем самой BL будет тот же, ей то пофиг что там в UI.
Ну и опять же — только стоит попробовать шагнуть в сторону, сразу по скорости будет лучше MVC.

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

G>В большинстве случаев доставался или один "заказ с позициями", поэтому лишняя сортировка в плане ни на что не влияла, или "список заказов", совершенно без затягивания лишних элементов.
Ты все еще не понимаешь. Этот пример наглядно показывает, что EF в принципе плохо генерит запросы меняя их в сторону удобства маппинга в ущерб оптимальности. Тебеж не зря ответили, что это не баг, а фича.

G>Ты конечно не поверишь, но у подавляющего большинства базовые сценарии, как я описал выше. А твой базовый сценарий встречается у двух с половиной человек.
Ты продолжаешь не понимать что такое базовый сценарий. Базовый сценарий для ORM — это не только конкретный left join (хотя и это тоже), а умение генерить качественный SQL в целом. EF за это упражнение — твердая двойка.

G>Чукча не читатель?
Я уже вижу кто здесь чукча — тебе уже и разжевали все, и примеры привели, и сами разработчики написали, что "фигня у нас получилась, заново делать будем", а ты все твердишь, что инструмент идеален... Расслабься уже, все у тебя есть.

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

G>Прости, но успехи в чтении пресс-релизов меня не интересуют.
А напрасно, иногда намного полезнее чем в форуме сраться Прочитал бы парочку, вдумчиво — глядишь и успокоился бы =)

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

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

G>>В большинстве случаев доставался или один "заказ с позициями", поэтому лишняя сортировка в плане ни на что не влияла, или "список заказов", совершенно без затягивания лишних элементов.
IB>Ты все еще не понимаешь. Этот пример наглядно показывает, что EF в принципе плохо генерит запросы меняя их в сторону удобства маппинга в ущерб оптимальности. Тебеж не зря ответили, что это не баг, а фича.
Это женская логика. Единичный пример не показывает ничего "в принципе". Также как единичный баг не говорит о качестве приложения "в принципе".

G>>Ты конечно не поверишь, но у подавляющего большинства базовые сценарии, как я описал выше. А твой базовый сценарий встречается у двух с половиной человек.
IB>Ты продолжаешь не понимать что такое базовый сценарий. Базовый сценарий для ORM — это не только конкретный left join (хотя и это тоже), а умение генерить качественный SQL в целом. EF за это упражнение — твердая двойка.
Докажи это, пока у тебя один конкретный пример. И тот легко обходится. Тебе уже более одного раза мягко намекали, что твой подход крайне непрофессионален.

G>>Чукча не читатель?
IB>Я уже вижу кто здесь чукча — тебе уже и разжевали все, и примеры привели, и сами разработчики написали, что "фигня у нас получилась, заново делать будем", а ты все твердишь, что инструмент идеален... Расслабься уже, все у тебя есть.
Я же говорю не читатель (или только читатель пресс-релизов). EF последовательно развивался с 2009 года, было 4 мажорных релиза и около 10 минорных. Никто не думал о переписывании, пока не появилось два кейса примерно в одно и тоже время — KRuntime и SQLite на Windows 8. На обоих EF не работает, просто исторически так сложилось, никогда не было целью обеспечить работу EF на мини-фреймворках. Поэтому собрались переписать.

Кстати из-за KRuntime еще и asp.net переписали, что же ты не рассказываешь всем что он сдох?

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

LE>Так же я бы на вашем месте присмотрелся бы к https://github.com/igor-tkachev/bltoolkit .
LE>Сам не работал(только собираюсь), но судя по всему очень крутая вещь. Ну и как минимум комьюнити не далеко(в соседней ветке форума ).

Лучше сразу использовать linq2db.

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

V>Поэтому в процедурах используется некоторое количество временных таблиц, вставок в них, индексов и даже местами dynamic sql.

linq2db поддерживает DDL операции, в том числе создание (временных) таблиц. Всё это мы с успехом используем в своём проекте и прекрасно обходимся без сохранённых процедур.

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

Н>Нынешний уровень аргументации -- не канает, увы.

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

С другой стороны, чтобы ты не говорил про "аргументация страдает", но сегодня сами разработчики признали EF ущербной библиотекой и собираются его переписывать с нуля. Ещё раз. Сами разработчики признали EF ущербной библиотекой и собираются его переписывать с нуля. Ваня же об этом говорит уже несколько лет. Думаю, это заслуживает внимания и уважения.

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

G>Это женская логика.
Сначала ты везде кричал, что они все поправили и SQL генерится самый лучший на свете. Я тебе показал, что это не так, но ты продолжаешь утверждать, что это фигня. Я тебе объяснил, что это косяк в архитектуре, а не просто ошибка, разработчики подтвердили тебе, что это by design, но ты все равно голову куда-то засовываешь. Вот это — женская логика.

G> Единичный пример не показывает ничего "в принципе". Также как единичный баг не говорит о качестве приложения "в принципе".
Еще один пример женской логики и неумения видеть проблему в целом.
Если единичный баг — системный и его нельзя поправить на протяжении нескольких лет потому что by design, то это таки говорит о качестве и архитектуре приложения "в принципе".


G> Тебе уже более одного раза мягко намекали, что твой подход крайне непрофессионален.
Душа моя, не тебе рассказывать мне про мою профессиональность. Мне глубоко не интересно, что думает о моей профессиональности человек, который не может вести диалог без перехода на личности и уж совсем не интересно собирать для него доказательную базу, если он очевидных примеров под носом не видит.

G> EF последовательно развивался с 2009 года, было 4 мажорных релиза и около 10 минорных.
Не с 2009, а с 2003 и не уверен, что эпитет "последовательно" здесь применим.

G> Никто не думал о переписывании, пока не появилось два кейса примерно в одно и тоже время — KRuntime и SQLite на Windows 8. На обоих EF не работает, просто исторически так сложилось, никогда не было целью обеспечить работу EF на мини-фреймворках. Поэтому собрались переписать.
И все таки — научись читать пресс-релизы. В жизни пригодится. Как минимум может помочь вовремя сбегать с мертвых технологий.
Снова цитирую реальные причины отказа от EF, а то ты похоже уже забыл или не дочитал:
we’ve had to take a realistic look at our current code base.
the code base is monolithic in nature which makes it difficult to implement new features and increasingly harder to change things without breaking existing functionality.
there are many seldom used features and capabilities in the code base that hamper performance and complicate development, but are not feasible to remove due to the monolithic nature of the implementation. We also have a number of unintuitive behaviors that are engrained into the framework and hard to change or remove for the same reasons.

А, и мое любимое, к вопросу об изначально неправильной идеологии, которая лежит в основе EF и до сих пор торчит изо всех мест:
When Entity Framework began life, it’s charter was more to do with the Entity Data Model vision rather than being a best-of-breed O/RM.

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

А>Проект в котором важна скорость обработки данных в СУБД. Избавится от использования хранимых процедур в таких проектах невозможно, иначе придется большие объемы данных тащить в приложение и потом обратно с базой их "джойнить",

Это неверное утверждение.