случае, нужно знать sql, думать в sql, переводить это как то в linq стиль, учитывать особенности и диалект субд, реализовать что то своими руками, чтобы в конце получить портянку кодгена, вместо того, чтобы сразу писать на sql.
"А если нам нужно будет поменять субд?"
Как часто меняют субд в проекте? А учитывать особенности этой субд не нужно? Переписывать код? Если у тебя такой код, что изменение субд не будет заметным, то и с sql это будет так же
Интересное мнение, но не понятно при чем тут абстракции, ef нужен не для абстракций, а для облегчения работы, в большинстве крупных проектов как минимум 80% работы с базой это тупые круды, в огромных количествах, к тому с кучей связей между таблицами, и набрасывать линк запросы на это получается значительно быстрее, плюс миграции, плюс контроль не только полей таблиц но и их типов, все это ускоряет работу раза в три по моим подсчетам. ЗЫ: А по поводу смены СУБД, согласен дикий бред... ))
Я не про ef, а про трансляцию
Там не понятно на что ваш пост.
"В целом, трансляция в sql ненужная вещь" 🙃🙃
А вы отделяете трансляцию от ef? Или все таки ваш пост можно читать как ef не нужен?
Тогда про какую трансляцию вы говорите?
Ef не только трансляция, а еще orm, миграции и тд
Трансляцию чего в sql, и чем? Я не понял вас
Linq запросов (но linq тут условный, может и не linq быть)
Ну нравится вам со строки в коде колошматить и читать потом, ваш выбор. Мне например это категорически не нравится
Дык, это от ide зависит
это от предпочтений зависит
Обсуждают сегодня