Аргументы против создают или обновляют
Недавно кто-то заявил, что они думали, что все Создает, должен быть CreateOrUpdates. Инстинктивно я думал плохо, но теперь я пытаюсь узнать, есть ли у меня какая-либо территория.
Ситуация
interface IService{
void Create(Object a);
void Update(Object a);
}
или
interface IService{
void CreateOrUpdate(Object a);
}
Моя первая мысль - то, при реализации всего CreateOrUpdate затем, Вы не имеете никакого контроля, если кто-то случайно отправляет Вам неправильно данные, или параллелизм выходит, где кто-то изменяет "основное" поле прямо перед вызовом обновления....
Но если Вы удаляете те случаи, есть ли какие-либо другие недостатки?
3 ответа
По-моему, все довольно просто: если вас беспокоит случайное создание записей, используйте два метода. Если вы не обеспокоены, используйте один.
А если вы не знаете, беспокоиться вам или нет, значит, вы не беспокоитесь. Используйте один метод.
Возможно, это слишком упрощенно, но обычно цель состоит в том, чтобы просто занести данные в базу данных.
В используемом нами фреймворке нет Create, только CreateOrUpdate. Мы никогда не сталкивались с ситуацией, когда нам нужно было просто Create.
Другими словами, это то, что было предложено, поэтому мы пошли с этим, и это нас еще не подвело. Системе уже два года, в ней около 300 столов.
В нашем случае мы не меняем первичные ключи, и если первичный ключ соответствует существующей строке, это не так.
Однажды я работал над приложением для финансовой отчетности, где обновления были запрещены, все изменения заключались в создании новых записей с обновленными данными. Это должно было предоставить полную историю изменений всех изменений учетной записи.