Ого, не знал о такой особенности в NET. Я знал, что там у ребят вообще отдельная кухня, но чтоб там ORM были настолько прокаченными - нет. Благодарю за ответ.
Согласен с тем, что в голом SQL через пару лет может что-то подзабыаться.
Но не совсем понимаю этот момент:
Это если используется ORM, тогда программа просто не скомпилится
Разве ORM при компиляции делает какие-то проверки между моделями и таблицами DB? Это какой-то функционал EF или в других ORM есть похожий механизм(могу судить только по SQLAlchemy - там такого нет)
Или речь про тесты ? В таком случае разницы между rawSQL и ORM быть не должно(все упрется в логику тестов).
ORM менее подвержен ошибкам. Легко ошибиться в одном из тридцати полей, набирая запрос руками.
Очень забавное утверждение)
Такая ошибка будет видна буквально в первом тестовом запуске на этапе разработки, поэтому ее цена - несколько человеко-минут. Лично я вообще разрабатываю с консолью в соседнем окне, чтобы сразу проверять корректность написанного запроса, поэтому шанс выкатить нерабочий запрос мизерный.
Это ещё даёт типобезопасность. Тип поля в классе всегда будет соответствовать типу данных колонки.
А это еще почему ? Если я запрошу
Select 1::int as field_a
А класс будет содержать field_a с типом string, то каким образом ORM обеспечит соответствие типов ? Если каким-то встроенным тайп-кастом, то, на мой взгляд, это не очень хорошо, так как не всегда понятно что к чему приводить(кто является эталоном - БД или приложение).
Ого, не знал о такой особенности в NET. Я знал, что там у ребят вообще отдельная кухня, но чтоб там ORM были настолько прокаченными - нет.
Благодарю за ответ.
Согласен с тем, что в голом SQL через пару лет может что-то подзабыаться.
Но не совсем понимаю этот момент:
Разве ORM при компиляции делает какие-то проверки между моделями и таблицами DB? Это какой-то функционал EF или в других ORM есть похожий механизм(могу судить только по SQLAlchemy - там такого нет)
Или речь про тесты ? В таком случае разницы между rawSQL и ORM быть не должно(все упрется в логику тестов).
Очень забавное утверждение)
Такая ошибка будет видна буквально в первом тестовом запуске на этапе разработки, поэтому ее цена - несколько человеко-минут. Лично я вообще разрабатываю с консолью в соседнем окне, чтобы сразу проверять корректность написанного запроса, поэтому шанс выкатить нерабочий запрос мизерный.
А это еще почему ? Если я запрошу
А класс будет содержать field_a с типом string, то каким образом ORM обеспечит соответствие типов ? Если каким-то встроенным тайп-кастом, то, на мой взгляд, это не очень хорошо, так как не всегда понятно что к чему приводить(кто является эталоном - БД или приложение).
Интересная и качественная статья. Спасибо автору за труд!