Страсти по делегатам
Я-то думал, ты в ЕФ шаришь
А ты теоретик.
Я в последнее время с ним давно не работал. Так, мелочь. В основном приходится со старым самописным дерьмом разбираться в теме общения с БД. Зато не всякое старьё APS.NET MVC использую, как некоторые, а новомодный Blazor. ))
Я в последнее время с ним давно не работал
мы ж тут не на собеседовании, можешь так и сказать, что написал хеллоуворлд на ЕФ и полтора курса прошел))
Вариант с == false генерерует в оракле вот такой запрос
и он гораздо медленнеее
SELECT "a"."ArtistId", "a"."Name" FROM "Artist" AS "a" WHERE 0 = CASE WHEN EXISTS ( SELECT 1 FROM "Album" AS "a0" WHERE "a0"."ArtistId" = "a"."ArtistId") THEN 1 ELSE o END
Не, почему, когда-то писал и code first, но теперь снова букварь надо читать, чтобы вспомнить, что там и как. Так-то подключиться к БД через контекст и что-то там позапрашивать могу - много ума не надо.
это я заметил.
у меня в соседнем проекте тоже коллеги местами не знают, в какой момент происходит запрос к БД.
На работе ценится не зазубривание букварей, а умение решать неожиданно всплывающие проблемы типа таких, когда не понимаешь, почему и откуда. Вон, народ по 15 и более лет всё понять не может, почему им Студия не называет конкретную причину ошибки, которая может остоять от декларированной на несколько шагов.
Странно, жалко Оракле снёс, интересно что дуреет.
вангую, что Oracle.ManagedDataAccess.EntityFramework.dll
На работе ценится не зазубривание букварей
Никто этого и не требует
Но понимать, сколько и в какой момент выполнится запрос в БД это гораздо важнее экономии 40% кода посредством использования новых фич.
а то напишешь, оно даже компилируется, на тестовой системе летает, а потом в проде умирает.
смотришь, а у ребят джойны в оперативной памяти происходят.
что Oracle.ManagedDataAccess.EntityFramework.dll
всё может быть, что Oracle.*
Oracle.ManagedDataAccess.Core
На работе ценится не зазубривание букварейНикто этого и не требует
Но понимать, сколько и в какой момент выполнится запрос в БД это гораздо важнее экономии 40% кода посредством использования новых фич.
а то напишешь, оно даже компилируется, на тестовой системе летает, а потом в проде умирает.
смотришь, а у ребят джойны в оперативной памяти происходят.
Если ребята с этим EF не работали, или мало работали - это нормально. Показать им, как надо, объяснить - в чём проблема?
это гораздо важнее экономии 40% кода посредством использования новых фич.
Это ещё и 40% понимания добавляет. Когда у тебя весь класс на одном экране, а не на пяти, потому что чел решил везде писать типа такого
private Obj _obj; public Obj Obj { get { if(_obj == null) { _obj = new Obj(); } return _obj; } }
вместо такого
private Obj _obj; public Obj Obj => _obj ??= new ();
А вообще, есть у кого-нибудь такие правила по оформлению кода, что типа в этом проекте запрещено использовать инициализаторы - нужно обычный конструктор и потом каждый раз созданному объекту свойства присваивать? Или свичи новые нельзя - только старые (которые statement, а не expression). Или нельзя использовать часть операторов - например ??= и прочие null-coalescing и null-propagation? Или нельзя bodies expressions (со стрелочками)? Нельзя лямбды - метод отдельный специально определяй. При этом язык и версия фреймворка позволяют. Т.е. нужно себя заставить писать где-то на уровне C# 2, но на версии C# 12 (.NET 8).
у нас тут на днях прислали coding standards
В принципе все норм, но какой-то старпер запретил использовать + для конкатенации строк. только StringBuilder. Пришлось объяснить, что оно не всегда нужно.
твоя простыня это же эквивалент ?
public Obj Obj = new Obj() {get;}
Не совсем. У вас нет модной ленивой инициализации.
public Obj Obj => _obj ??= new ();
Мало того, что при чтении этого ломается мозг, так тут еще и существует опасность забыть знак равно и получать каждый раз новый объект.