- Плохой нейминг, последнее, чего ожидаешь от ToHash() — это то что он полезет в базу да еще и с апдейтом.
— если не используются nullable reference types, то request?.Url в обоих случаях а лучше var requestUrl = request?.Url и дальше юзать переменную.
— если _context EF, то последнее действие "сохранить все", соответственно предпоследнее достаточно просто обновить trackable пустем добавления в in-memory коллекцию, при правильной настройке Id будет заретрофичен после сохранения. В любом случае операции с _context нужно выносить в repository.
— выше писали про мутабельный Url — тут этого, конечно, нет, от силы плохие названия методов, хаш создается чтобы не светить Id наружу или что то в этом роде.
— если копать глубже, можно смотреть на single reposibility и иммутабельность метода, странновато добавлять Url без проверки на существование, нуждается в перепроверке, опять же вынос в репозиторий облегчает это.

- Плохой нейминг, последнее, чего ожидаешь от ToHash() — это то что он полезет в базу да еще и с апдейтом.
— если не используются nullable reference types, то request?.Url в обоих случаях а лучше var requestUrl = request?.Url и дальше юзать переменную.
— если _context EF, то последнее действие "сохранить все", соответственно предпоследнее достаточно просто обновить trackable пустем добавления в in-memory коллекцию, при правильной настройке Id будет заретрофичен после сохранения. В любом случае операции с _context нужно выносить в repository.
— выше писали про мутабельный Url — тут этого, конечно, нет, от силы плохие названия методов, хаш создается чтобы не светить Id наружу или что то в этом роде.
— если копать глубже, можно смотреть на single responsibility и сюда же idempotency метода, странновато добавлять Url без проверки на существование, нуждается в перепроверке, опять же вынос в репозиторий облегчает это.