Здравствуйте, Titus, Вы писали:
T>Здравствуйте, namespace, Вы писали:
T>>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM. N>>Для маппинга, и только.
T>Ну вот здесь, я, пожалуй, соглашусь. Во всяком случае, давно сделал себе небольшую генерилку классов из из БД. T>Кстати, не я один такой. Пример такой генерилки, можно найти в интернетах, здесь, например https://stackoverflow.com/questions/5873170/generate-class-from-database-table T>Обратите внимание на размер сорс кода этого "ORM" — 59 строчек. T>Но это принцип, прямо противоположный принципу "Code First".
Ну вот и еще один велосипед от недовольных EF. Скажете чем ваш ORM лучше linq2db?
Спрашиваю потому что я один из его разработичков. С уверенностью могу сказть что мы быстрее Dapper, хотя и используем linq. Балк операции и все такое, поддержка более дюжины баз данных.
И да, мы тоже считаем database first более верным подходом.
Здравствуйте, namespace, Вы писали:
T>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM. N>Для маппинга, и только. Ни один орм не умеет оптимально генерировать сложные запросы. А читать эти сложные запросы — проще повеситьсяподсмотреть в профайлере. Максимум что можно — написать выборку с where. N>А без маппинга много ручной работы.
Вызываю вас на дуель. Я считаю что linq2db строит супер запросы. Я писал трехэтажные квери, которые оптимизировались, как на меня, практически идеально.
Здравствуйте, serrrgi0, Вы писали:
S>Т.е. по вашему факта того, что Люди не знающие ЯП могут сгенерировать класс и на основании класса таблицу S>не достаточно чтобы существовали ORM? S>Я вас верно понял?
Неверно. Если ORM существует, значит это кому-то нужно.
Вопрос был изначально поставлен так: зачем нужен ORM тем, кто знает SQL и давно работает с различными СУБД?
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, Titus, Вы писали:
T>>Просто когда пользуешься чем-то, нужно включать мозг — не надо давать этот метод на вход вебформ в неприкрытом виде.
S>А "прикрытый вид" — это экранирование и склейка, или для веб-форм предлагаете отдельный метод завести?
Валидация ввода идет на трех этапах:
1) View — скорее для честных людей.
2) Controller — в Model числа отправляет, как числа, а не как строки.
3) Model — валидирует и при необходимости преобразует строки на предмет исключения причин заваливания запроса и инъекций.
В принципе, если клоунадой заниматься не собираешься, можем проверить устойчивость такого подхода на конкретных примерах.
Здравствуйте, Danchik, Вы писали:
D>Ну вот и еще один велосипед от недовольных EF. Скажете чем ваш ORM лучше linq2db?
Я не знаю. Я ж не против linq2db. Мне нужны аргументы "за". Мой ORM — это полуавтоматизированное "рукоблудие".
Оно требует времени, и я бы с удовольствием его сократил, если бы мне linq2db помог.
D>Спрашиваю потому что я один из его разработичков.
Это хороший признак.
Здравствуйте, Danchik, Вы писали:
D>Здравствуйте, namespace, Вы писали:
T>>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
D>Вызываю вас на дуель. Я считаю что linq2db строит супер запросы. Я писал трехэтажные квери, которые оптимизировались, как на меня, практически идеально.
Принимаю вызов. Нужна конкретная задача. Желательно, не очень большая. Желательно Database First.
Ну просто по факту мы приходим со своей автоматизацией не в пустыню, а в уже сложившуюся инфраструктуру заказчика.
И нужно коннектиться к тому, что есть, хотя и приходится создавать что-то свое.
Здравствуйте, Titus, Вы писали:
T>Неверно. Если ORM существует, значит это кому-то нужно. T>Вопрос был изначально поставлен так: зачем нужен ORM тем, кто знает SQL и давно работает с различными СУБД?
bnk>Обычно это не так, и разработка+поддержка с ORM заметно более эффективна в плане временных затрат, чем написание sql в коде.
M>то есть фактов наличия и использования этих самых ORM тебе недостаточно в качестве пруфов?
T>Именно так. "Все так делают" — для меня не аргумент.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, serrrgi0, Вы писали: S>>Вы этот код с какой СУБД использовали?
T>Я этот код не использовал. Он не мой. Но он понравился на стэковерфлоу ~500 людям. T>А я давно написал свой код, его использую )
Зачем тогда его приводили его для примера и заставили меня показать его недостатки?
Здравствуйте, Titus, Вы писали:
T>Валидация ввода идет на трех этапах: T>1) View — скорее для честных людей. T>2) Controller — в Model числа отправляет, как числа, а не как строки. T>3) Model — валидирует и при необходимости преобразует строки на предмет исключения причин заваливания запроса и инъекций.
T>В принципе, если клоунадой заниматься не собираешься, можем проверить устойчивость такого подхода на конкретных примерах.
И ещё раз: использование параметризованных запросов — это абсолютно базовая практика безопасности для защиты от sql-иньекций. Вы предлагаете (зачем-то) делать всё что угодно, кроме этого.
А насчёт "устойчивости такого подхода": что надёжнее — доверить драйверу базы данных обеспечивать безопасность использования данных, или пытаться это делать самому? Учитывая что особенности экранирования значений могут быть специфичны для баз данных? (И учитывая что вы сами говорите о "низкой квалификации разработчиков")
Здравствуйте, Titus, Вы писали:
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
шёл 2018й год, а "высококвалифицированные программисты"(tm) до сих пор не знают, зачем нужен ORM
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Философ, Вы писали:
Ф>>>>Для того чтобы не пилить руками простейшие запросы T>>>1) Так и в ORM тоже руками нужно работать. T>>>2) Для тех, кто любит водить мышкой, в СУБД тоже есть case средства разработки запросов типа Query-By-Example
Ф>>Я не говорил про работать мышкой. T>Ты говорил про «не пилить руками простейшие запросы»
Да, но это не означает, что их можно сделать мышкой. Запросы всё равно пишутся, но пишутся на твоём родном ЯП, а не хардкодятся строки с SQL'ем в код.
Ф>>При использовании, ORM запросы не хардкодятся, а пишутся с использованием ORM. T>Каков слог! ) А чем отличается «хардкодятся» от «пишутся с использованием ORM»?
Пушутся — пишутся на родном ЯП. Хардкоядтся — это зашиваются в код в виде строк, типа вот этого
voind Main()
{
...
connection.User = "\'; select Name from Users Where ID_User=1";
connection.Password = "\';";
connection.Open();
}
Ф>>А тот код, который нагенерила ORM поддерживать не нужно: как нагенерировала, так и перегенерирует.
Не нужно. Туда вообще лазить не нужно. Ты софтину пишешь, а не ORM.
T>А теперь следите за руками! Все что нагенерировала ORM, доступно для редактирования руками. И поскольку автоговнокод далек от оптимального, возникает желание, а главное, необходимость подредактировать автоговнокод руками. T>А теперь внимание вопрос: после «доработки напильником» что перегенерирует ORM?
Не нужно. Туда вообще лазить не нужно. Ты софтину пишешь, а не ORM.
Ф>>Автотесты ещё писать нужно — это время, это внимание => это ошибки. T>Ну это отдельный топик: «Зачем нужны автотесты?» — этот вопрос, кстати, у меня не возникает. Затраты на автотесты на моей практике окупаются (в деньгах) уже на третьем регрессионном тестировании.
Не нужно тестировать в рантайме то, что можно протестировать в компилтайме.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Somescout, Вы писали:
S>>Что, и даже запрос не параметризованный? Склейка, экранирование и sql-иньекции наше всё?
T>Просто когда пользуешься чем-то, нужно включать мозг — не надо давать этот метод на вход вебформ в неприкрытом виде.
Не дашь перед — залезем через зад: ты сам положишь SQL код в базу, сам оттуда его выберешь, склеишь и выполнишь.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, namespace, Вы писали:
T>>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM. N>>Для маппинга, и только.
T>Ну вот здесь, я, пожалуй, соглашусь. Во всяком случае, давно сделал себе небольшую генерилку классов из из БД. T>Кстати, не я один такой. Пример такой генерилки, можно найти в интернетах, здесь, например https://stackoverflow.com/questions/5873170/generate-class-from-database-table T>Обратите внимание на размер сорс кода этого "ORM" — 59 строчек.
Я когда-то тоже делал. "Промышленные" оказались гибче и удобнее.
T>Но это принцип, прямо противоположный принципу "Code First".
это вообще нафиг.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Danchik, Вы писали:
D>>Здравствуйте, namespace, Вы писали:
T>>>>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
D>>Вызываю вас на дуель. Я считаю что linq2db строит супер запросы. Я писал трехэтажные квери, которые оптимизировались, как на меня, практически идеально.
T>Принимаю вызов. Нужна конкретная задача. Желательно, не очень большая. Желательно Database First.
T>Ну просто по факту мы приходим со своей автоматизацией не в пустыню, а в уже сложившуюся инфраструктуру заказчика. T>И нужно коннектиться к тому, что есть, хотя и приходится создавать что-то свое.
Databse First, это именно наш подход. Генерим классы из базы при чем с возможностью полной кастомизации генерации. Цепляйтесь к любой инфраструктуре какой хотите, вплоть до подхватывания текущей транзакции.
Я чесно не вижу кейса когда мы с чем то не свяжемся.
Мы даже к EF зацепились с малой кровью https://github.com/linq2db/linq2db.EntityFrameworkCore
Здравствуйте, Titus, Вы писали:
T>Маневров для оптимизации больше (после того, как черепаху в продакшн выпустили) и т.д. Если заказчик богат, то с него можно снять несколько урожаев за один и тот же продукт.
T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Если ты один работаешь над проектом и никто кроме тебя этим заниматься не будет, то ORM и не нужен
Здравствуйте, Titus, Вы писали:
Ф>>Для того чтобы не пилить руками простейшие запросы T>1) Так и в ORM тоже руками нужно работать. T>2) Для тех, кто любит водить мышкой, в СУБД тоже есть case средства разработки отчетов типа Query-By-Example
Ф>>А потом учти, что поддреживать код, использующий орм проще, чем код с тучей SQL'я, T>Вот как-то не заметил... код, сгенерированный ORM, — это туча еще большего размера.
Он генерируется, потому стоимость поддержки этой тучи стремится к нулю. Тебя ведь не заставляют эту тучу вручную патчить?
Здравствуйте, Danchik, Вы писали: D>>>Вызываю вас на дуель. Я считаю что linq2db строит супер запросы. Я писал трехэтажные квери, которые оптимизировались, как на меня, практически идеально.
T>>Принимаю вызов. Нужна конкретная задача. Желательно, не очень большая. Желательно Database First.
D>Я чесно не вижу кейса когда мы с чем то не свяжемся.
Да тут вопрос не в "свяжемся", а в скорости работы с/без ORM.
Ты вызвал на дуэль, я выбираю "оружие" ))
Я поставлю задачу, "основанную на реальных событиях".
Ты ее решаешь с помощью linq2db.
Я без использования ORM.
Каждый записывает процесс решения скринкастингом на видео. Можно также добавить звук.
Выкладываем ролики на Ютьюб на всеобщее обозрение.
Если я проиграю, то на самом деле я выиграю, ибо увижу, как прекрасен linq2db, и удивлюсь сам себе, как я раньше "одевал штаны через голову".
А ты получишь наглядную и конкретную рекламу и доказательство того, что linq2db — и в самом деле крут.
по шагам:
1) Я ставлю задачу
2) Ты ее решаешь с помощью linq2db в режиме скринкастинга и показываешь результат мне.
3) (после п.2) Я ее решаю без ORM в режиме скринкастинга и показываю результат тебе.
4) Мы выкладываем наши результаты на всеобщее обозрение.
Согласен? Готов?
Хотя задача не сложная, п.3. может занимать до недели, потому что у меня куча других дел. Прошу сразу это понять и принять.
Здравствуйте, Somescout, Вы писали:
S>И ещё раз: использование параметризованных запросов — это абсолютно базовая практика безопасности для защиты от sql-иньекций. Вы предлагаете (зачем-то) делать всё что угодно, кроме этого. S>что надёжнее — доверить драйверу базы данных обеспечивать безопасность использования данных, или пытаться это делать самому?
Мистер теоретег, вы в курсе, что тот же OleDB не поддерживает некоторые параметризованные select запросы для некоторых СУБД. Что это? — Незадокументированная фича, или ошибка — вопрос второй.
Вопрос первый: как сделать так, чтобы программа, работавшая с одной СУБД работала бы также и с другой?
