AP>>CheckAllQueries автоматически генерирует тесты для всех вариантов всех запросов НС>Тесты это хорошо, но руками править кучу текстовых запросов вместо решарпера при простейшем переименовании поля или таблицы — это надо быть очень убежденным в своей правоте.
Не забываем, что еще есть FindUsages. FindUsages выдаст список [File, Line]. [File, Line] указывает на начало метода с запросом, а там Ctrl-F. А CheckAllQueries это всё проконтролирует. Поэтому не так всё страшно. Используя Roslyn, можно точно позиционироваться на колонку/таблицу (пока не реализовано).
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>2) Люди пишут Linq запросы не понимая что происходит в базе. Особенно часто встречается FirstOrDefault, который в SQL работает очень медленно, или банально вызывают функции в предикатах.
IT>Что за проблема с FirstOrDefault?
Потому что внутри запроса он преобразуется в select top 1 from (select rownumber() over (...) from t) при некоторых условиях (группировка и еще что-то).
AP>>Если не сложно опиши, как в таком режиме работать с EF? IT>А в чём тут проблема?
Проблем нет. Просто хотел уточнить свое понимание. Тексты классов являются перегенерируемыми, т.е. около полей ничего не пишем руками? (иначе всё снесется) В одном из туториалов видел как вручную навешивались ASP MVC атрибуты, значит, это был неправильный туториал.
IT>И как ощущения? Для меня сегодня рефакторинг БД ничем не отличается от обычного рефакторинга кода. Т.е. вообще ничем. Когда же я писал SQL руками, то это был невероятный геморой.
В связи с этим можно у тебя поинтересоваться, на чём у вас UI? Я очень интересуюсь полным пакетом технологий, где статическая типизация везде: на БД уровне, на серверном и на UI. У вас десктоп или web? Если веб, то html формируете на сервере? или на клиента только данные в виде json уходят? Если второе какой-нибудь клиентский фреймворк используете AngularJS, Ember.js и т.д.? TypeScript используете?
Вроде после появления TypeScript моя мечта о полной статической типизации приложения забрезжила на горизонте. Видимо, какой-то Remote Facade должен быть между клиентским TS и серверным C#. Есть уже что-то готовое для этого?
Здравствуйте, gandjustas, Вы писали:
IT>>Что за проблема с FirstOrDefault? G>Потому что внутри запроса он преобразуется в select top 1 from (select rownumber() over (...) from t) при некоторых условиях (группировка и еще что-то).
Это такое EF генерит? Жуть.
Если нам не помогут, то мы тоже никого не пощадим.
IT>И как ощущения? Для меня сегодня рефакторинг БД ничем не отличается от обычного рефакторинга кода. Т.е. вообще ничем. Когда же я писал SQL руками, то это был невероятный геморой.
Рефакторинг же не конечная цель. Конечная цель это постепенно строить и развивать приложение. И рассматривать отвлеченные переименование таблицы/колонки не интересно.
Если доступ к базе не покрыт ни тестами, ни статической типизацией, то, да, вносить изменения очень боязно, поэтому это сильно тормозит развитие, а разработчики начинают серьезно играть в игру угадай будущее. Что несомненно плохо. А вот разница между случаем, когда есть тесты, и случаем, когда есть статическая типизация, эта разница уже не такая существенная. Разработчики без проблем вносят изменения в базу, поскольку есть уверенность, что их ошибки отловятся и они не отдадут поломанное приложение в продакшен.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>EF — это всё же отдельно от всего лежащий кусок кала. G>>Года два назад отдали в ASP.NET IT>Т.е. его пилят уже не те индусы, которые завалили WinFS?
В МС результат мало зависит от индусов, они обычно пилят то, что скажут. Результат зависит от менеджеров прогдакт-группы. Сейчас у asp.net похоже самые толковые менеджеры.
IT>>>Ваня правильнос сказал, что практикующим девелоперам ещё лет 10 назад стало понятно каким должно быть средство работы с БД. Но команда EF шла на пролом своим путём. G>>Если всем понятно, то почему никто не сделал?
IT>Во-первых, написание полноценного Linq-провайдера — это не тривиальная задача типа unit testing framework. Лет пять назад в MS эту задачу оценивали в пару лямов.
Слабая отмазка, в Open Source уже немерено этих провайдеров, а IQToolkit появился вместе с .NET 3.5. Если бы новый провайер мог решить реальные проблемы, а не сущетвующие только в голове отдельных личностей, то уже давно бы это сделали.
IT>Во-вторых, большинство попыток следуют текущей конъюнктуре и в конце концов сваливаются к созданию heavy-ORM.
Какой такой конъюнктуре?
IT>В-третьих, сделали. linq2db не страдает ORM-ностью и представляет собой скорее типизированный SQL.
И что? Проблемы решились? Где толпы восторженных пользователей? Гуглг по linq2db находит репы, NuGet пакеты и целое одно сообщение на rsdn давностью больше полугода.
IT>>>Новый компилятор позволяет переписать устаревший код и сделать его лучше. Но новый компилятор не поможет сделать лучше новую архитектуру. G>>Да ладно? Например с помощью compiler as service можно сделать compile time генерация маппинга DataReader на объекты как минимум или запросто компилировать в реальный IL edmx-модель, убрав весь оверхед, или делать compile-time проверяемые текстовые запросы с декомпозицией (как мечтает Поляков).
IT>Убрать весь оверхед не получится. То, о чём ты говоришь — это лишь несколько процентов сценариев использования. Но даже маппинг одного и того же объекта может отличаться. Например:
IT>
IT>from t in Table select t;
IT>from t in Table select new { t.Filed1.Length, t };
IT>
IT>Во втором случае индексы для маппинга t съедут на 1 и придётся наворачивать весь оверхед обратно. К тому же это всё не является серьёзной проблемой. linq2db строит expression tree для каждого запроса со всеми необходимыми маппингами без всякого оверхеда в run-time, потом компилирует его и кеширует. Эффективность такого решения примерно как у параноидального ручного маппинга с индексами вместо имён полей.
Верю. И что? Для меня вообще скорость маппинга не была никогда проблемой. При тех нагрузках, где скорость мапинга хоть что-то решает я использую кеширование и на скорость мапинга становится пофиг. Это IB беспокоит скорость мепинга, а по моим замерам ef тратит на мепинг одного объекта на 0,2 мкс (две десятых миросекунды, 2*10^-7 секунд) больше, чем при ручном мепинге (проверял на резалтсете из 5000к элементов). Кстати это составляет примено тысячную часть часть от времени запроса, без чтения с диска.
Я вот даже не могу представить причину по которой меня (или кого либо) должны такие "тормоза" беспокоить.
G>>Возвращаясь к теме EF — начиная с версии 5 активно внедряется такой же сервисный подход. Тоже есть встроенный IoC, тоже куча подменяемых сервисов и соглашения (положительное влияние asp.net). Но под капотом там еще остался старый EF, построенный на принципах ООП, который и хотят в версии 7 выкорчевать из EF. IT>Честно говоря, мне не очень понятно, что там нужно такого расширяемого в linq-провайдере
Скорее всего в самом Linq провайдере и не будет особой расширяемости по сравнению с предыдущей версией.
Кстати для замеров добавил linq2db в тестовый проект, оказалось что TT генератор хреново работает с базами, у которых точки в имени, а также напрягло что завязано на .config файл. В KRuntime хотят отказаться от идеи обязательного конфига, да и сейчас много сред, где конфиг недоступен.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Странная логика, любая архитектура — набор ограничений. Заранее ты не знаешь какие цели будут поставлены. То есть в принципе любая архитектура кривая.
НС>Ты вообще не понимаешь, похоже, что тебе пишут. Проблема не в том что архитектура кривая, а в том что изначальные цели и требования были сформулированы неверно. А кривая архитектура — лишь следствие. НС>Ты внимательно почитай что авторы пишут: "there are many seldom used features and capabilities in the code base". Умные люди еще с ранних бета-версий EF говорили именно об этом (посмотри на LINQ часть BLT или linq2db, там почему то этих мегафич нет). Но понадобилось куча времени и релизов, чтобы до разработчиков EF наконец дошло.
По прядку.
1) "Дошло" до команды EF только тогда, когда понадобилось портировать EF на WinRT (читай "телефоны"). Когда создавался EF никто и представить не мог, что вообще будет WinRT. По большому счету сейчас ни один ORM в телефоне не заработает, так же как EF. Будем считать что у всех архитектура кривая.
2) Куча редкоиспользуемых фич никого не беспокоит (кроме тех, кто активно цитирует пресс-релиз в этой теме).
3) Мега-тормоза, о которых также любят писать некоторые люди в этой теме, тоже мало кто видел. Лично я сталкивался с тормозами EF и решал эту проблему парой строк кода, в текущей версии все эти решения автоматизированы.
Я прекрасно понимаю что тут пишут, и прекрасно понимаю, что это совершенно не проблемы для подавляющего большинства программистов.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Что за проблема с FirstOrDefault? G>>Потому что внутри запроса он преобразуется в select top 1 from (select rownumber() over (...) from t) при некоторых условиях (группировка и еще что-то).
IT>Это такое EF генерит? Жуть.
Помоему это было в Linq2SQL, не помню уже. Там был кейс, что такой SQL, единственный, который давал результат, аналогичный результату на списке объектов. Причем, по странному стечению обстоятельств, таких запросов в коде было дофига.
НС>Тесты это хорошо, но руками править кучу текстовых запросов вместо решарпера при простейшем переименовании поля или таблицы — это надо быть очень убежденным в своей правоте.
Всякие Фаулеры, проповедующие аджайл, на тесты и уповают, у них и языки часто динамические.
Забавно
Здравствуйте, Alexander Polyakov, Вы писали:
AP>>>Если не сложно опиши, как в таком режиме работать с EF? IT>>А в чём тут проблема? AP>Проблем нет. Просто хотел уточнить свое понимание. Тексты классов являются перегенерируемыми, т.е. около полей ничего не пишем руками? (иначе всё снесется) В одном из туториалов видел как вручную навешивались ASP MVC атрибуты, значит, это был неправильный туториал.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>В связи с этим можно у тебя поинтересоваться, на чём у вас UI?
Традиционно WPF и ASP.NET MVC. Т.е. тут даже думать не надо. MVVM и MVC требуют для себя отдельной модели, которая с DataModel пересекаться может, но редко и не долго, ровно до тех пор пока не начнётся усложнение UI. Т.е. для себя я давно решил, что модель данных приложения ака DataModel, необходима исключительно для того, чтобы работать с БД. Кстати, BLT и linq2db поддерживает параноидальный режим описания метаданных БД в виде интерфейсов, а не классов, что вообще искючает создание экземпляров объектов модели данных. Т.е. модель данных используется исключительно для запросов к БД. В целом это работает неплохо, учитывая, что большая часть запросов в реальном приложении представляют собой ad-hoc запросы и требуют перекладывания данных из БД в модель MVVM или MVC.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Alexander Polyakov, Вы писали:
AP> Если доступ к базе не покрыт ни тестами, ни статической типизацией, то, да, вносить изменения очень боязно, поэтому это сильно тормозит развитие, а разработчики начинают серьезно играть в игру угадай будущее.
Юнит тесты — это прежде всего дорого и долго. К тому же наличие статической типизации делает большинство юнит тесов, которые делалются как раз из-за её отсутствия, бессмысленными. Т.е. и здесь linq серьёзно способен удешевить разработку.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>В МС результат мало зависит от индусов, они обычно пилят то, что скажут. Результат зависит от менеджеров прогдакт-группы. Сейчас у asp.net похоже самые толковые менеджеры.
Ну будем надеяться.
IT>>Во-первых, написание полноценного Linq-провайдера — это не тривиальная задача типа unit testing framework. Лет пять назад в MS эту задачу оценивали в пару лямов. G>Слабая отмазка, в Open Source уже немерено этих провайдеров, а IQToolkit появился вместе с .NET 3.5. Если бы новый провайер мог решить реальные проблемы, а не сущетвующие только в голове отдельных личностей, то уже давно бы это сделали.
Отмазка вполне серьёзная. Тот же IQToolkit более как на роль примера linq-провайдера больше ни на что не тянет. Реально его пытался использовать только автор Subsonic, который в результате на OrmMetter не был допущен к забегу в категории linq из-за фейла почти всех linq-тестов.
В общем, если бы я точно знал куда я лезу, когда начинал заниматься linq-провайдером в BLT, то точно бы не стал этого делать и сейчас, скорее всего восхвалял EF вместе с тобой и точно так же спорил бы с IB
IT>>Во-вторых, большинство попыток следуют текущей конъюнктуре и в конце концов сваливаются к созданию heavy-ORM. G>Какой такой конъюнктуре?
Все хотят построить не просто маппер, а охренительный умный всемогутер, который сам знает что нужно разработчику ещё до того как разработчик об этом подумал. Тот же Unit Of Work, на самом деле, вполне имеет право на жизнь в некоторых случаях. Но проблема в том, что конъюнктурщики начинают именно с него, а всё остальное в результате идёт по-боку, потому что на это элементарно не хватает ресурсов. Мне, кстати, тоже сильно не хватает ресурсов, в частности на тот же Unit Of Work, но зато мне их хватило на генерацию вменяемого SQL для FirstOrDefault, для поддержки более десятка БД, для генерации human friendly SQL, который не нужно переформатировать, чтобы на него посмотреть и прочих вещей, нужных не для демонстраций, а для каждодневной работы.
IT>>В-третьих, сделали. linq2db не страдает ORM-ностью и представляет собой скорее типизированный SQL. G>И что? Проблемы решились? Где толпы восторженных пользователей? Гуглг по linq2db находит репы,
Я программист, а не пиарщик. Видимо в этом проблема. К тому же см. выше про ресурсы. Кто-то их тратит на написание кода, а кто-то на толпы восторженных пользователей.
G>NuGet пакеты и
Вообще-то есть целый форум про это дело. К тому же linq2db это как раз переработка BLT в части linq и всё, что касается BLT можно отнести к linq2db.
G>Верю. И что? Для меня вообще скорость маппинга не была никогда проблемой.
Тогда зачем ты это приводил в качестве аргумента? На самом деле метапрограммирование в этом деле вовсе не бесполезно. Например, модель данных запросто можно генерировать в момент компиляции, а не с помощью T4.
G>Кстати для замеров добавил linq2db в тестовый проект, оказалось что TT генератор хреново работает с базами, у которых точки в имени,
Давай пофиксим вместо. Давай пример неработающего кода, будем фиксить.
G>а также напрягло что завязано на .config файл. В KRuntime хотят отказаться от идеи обязательного конфига, да и сейчас много сред, где конфиг недоступен.
Всё можно сконфигурировать и без конфигов. Последние пять лет у меня это вообще была единственная доступная опция.
Если нам не помогут, то мы тоже никого не пощадим.
Резултат тот же. Может у тебя не самая свежая версия. Я довно nuget не обновлял. Может в этом проблема.
AP>P.S. По хорошему, Parent свойство должно быть Option<Parent>.
Да это как бы тоже не проблема. Можно покумекать над расширением маппинга для твоего собственного Option<T>.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>Помоему это было в Linq2SQL, не помню уже. Там был кейс, что такой SQL, единственный, который давал результат, аналогичный результату на списке объектов. Причем, по странному стечению обстоятельств, таких запросов в коде было дофига.
Ну незнаю, обычного TOP 1 хватает за глаза. Для Single(OrDefault) TOP 2. Но даже это всё не обязательно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Не забываем, что еще есть FindUsages. FindUsages выдаст список [File, Line]. [File, Line] указывает на начало метода с запросом, а там Ctrl-F.
И так 50 раз. И это вместо того чтобы просто один раз нажать хоткей и ввести новое имя.
Если нам не помогут, то мы тоже никого не пощадим.
