DbContext.SaveChanges описывает, какие исключения вы можете ожидать.Решите, какие исключения вы хотите поймать, а какие нет.
Если вы не уверены, какие исключения вы получаете в каких ситуациях, используйте отладчик и некоторый тестовый код, чтобы выяснить, какие исключения вы действительно можете ожидать:
// TODO: create one of your error conditions
try
{
_context.SaveChanges();
}
catch (Exception e)
{
Console.WriteLine(e.GetType()); // what is the real exception?
}
Когда вы знаете, какие исключениявы можете ожидать, и какие из них вы действительно можете обработать, напишите ваш окончательный код:
try
{
_context.SaveChanges();
}
catch (DbUpdateException e)
{
// handle the update exception
}
catch (DbEntityValidationException e)
{
// handle the entity validation exception
}
catch (...)
Вы, вероятно, не поймаете System.NotSupportedException, ваш код должен быть таким, чтобы он использовал только поддерживаемые операторы LINQ.
Оптимизация
Имейте в виду, что DbSets
в вашем DbContext
представляет таблицы в вашей базе данных.Классы в DbSets
представляют строку в таблице: не виртуальные свойства представляют столбцы в таблице, отношения между таблицами представляются в виде виртуальных свойств.
Вы разработали эти таблицы базы данных, потому что выхотел решить проблему.Очевидно, в вашем решении было важно, чтобы FirstName / LastName и т. Д. Не были бы нулевыми.
Вы, вероятно, свернете использование вашего DbContext в класс, который скрывает, что вы используете структуру сущностей для хранения ваших данных вместонапример, Dapper, или любой метод более низкого уровня для запроса и обновления данных.
Довольно часто этот класс-оболочку называют классом Repository
: пользователи вашего Repository
не знают и действительно не понимаютвсе равно, как и где вы сохраняете свои данные: SQL?Монго?Может быть, даже CSV-файл?
Приятно иметь класс Repository
в том, что, если вы решите изменить макет таблицы или если вы решите изменить один из ваших запросов в хранимую процедуру,или если вы решите сохранить свои данные в CSV, изменения будут минимальными, и пользователи даже не заметят это изменение
В вашем хранилище будут функции для запроса лиц, добавления / удаления / обновленияЛицо и т. Д. Ранее вы решили, что ваше решение не должно принимать лиц с нулевыми именами.
Ваше решение не зависит от того, как ваши данные сохраняются.Следовательно, ваше решение не должно зависеть от того, проверяет ли ваш репозиторий, являются ли ваши имена пустыми или нет.
Рекомендуется проверить правильность данных перед вызовом SaveChanges .В этом случае: проверьте, действительно ли имя, фамилия и т. Д. Не равны нулю.Ваш код будет
- выглядеть чище: меньше обработки исключений, создаваемых сторонами, находящимися за пределами вашей сферы охвата
- легче читать: читателям не придется гадать, что произойдет, если данные равны нулю,
- проще в тестировании: ваш тестовый код может использовать простой репозиторий-макет без нулевых проверок
- , лучше поддерживаемый: если вы решите добавить людей без имени, модель вашей базы данных не изменится,только ваш класс хранилища