MonochromatiqueEF: Есть ли способ сохранить объект в БД, не зная есть он там или нет?

Есть ли у данной задачи смысл? Можешь поделиться? Очень интересно.

MonochromatiqueЕсли ответ - НЕЛЬЗЯ, то понятно - значит надо его искать в БД перед сохранением, вот и весь смысл. Чтобы это понять - и был сформулирован этот вопрос.

Да можно, но лучше не надо. Вот прям настаиваю, что не надо. Просто не надо, если нет на то веских причин. Спросил, чтобы понять является ли причина веской или нет.

MonochromatiqueЗамороченный он какой-то, EF этот...

Ну есть немного. Но проблема в том, что ты хочешь натянуть на EF какой-то свой сценарий работы с данными, вместо того, чтобы разобраться как работает и почему именно так устроен EF. Да, он предлагает в качестве основной одну стратегию и вокруг неё всё вертится. Для изменения данных в EF надо вытащить объект, изменить его, затем сделать SaveChanges. Так он работает. Это не значит, что другого пути совсем нет. Хочешь, пихни чистый SQL, но не жди согласованности контекста, что значит потери львиной доли смысла EF.

MonochromatiqueСамый смех, что если бы я плюнул на всю эту virtual lazy context и работал исключительно бы с простыми типами - проблем бы не было.

До сих пор существуют люди, не воспринимающие никаких ORM, даже micro-ORM, предпочитая собирать свой, чистый, кошерный SQL с помощью манипуляций со строками. Ну и ниче так, живут себе, кодят...

skyANAОфигеть какой избыточный код: How to create an upsert method

Проверять по значению Id на ноль, это весьма оригинально