Аргументы против создания или обновления - PullRequest
5 голосов
/ 19 мая 2010

Недавно кто-то заявил, что он считает, что все Creates должны быть CreateOrUpdates. Инстинктивно я думал плохо, но теперь я пытаюсь выяснить, есть ли у меня какие-либо основания.

Положение

  interface IService{
    void Create(Object a);
    void Update(Object a);
  }

или

   interface IService{
       void CreateOrUpdate(Object a);
  }

Моя первая мысль: если вы реализовали все CreateOrUpdate, то у вас нет контроля, если кто-то случайно отправит вам неправильные данные, или возникнут проблемы с параллелизмом, когда кто-то изменяет «основное» поле прямо перед вызовом update ....

Но если вы удалите эти случаи, есть ли другие минусы?

Ответы [ 3 ]

3 голосов
/ 19 мая 2010

Мне кажется, это довольно просто: если вас беспокоит случайное создание записей, используйте два метода. Если вы не заинтересованы, используйте один.

И если вы не знаете, следует ли вам беспокоиться или нет, вас это не касается. Перейти с одним методом.

Может быть, это слишком упрощенно, но обычно цель состоит в том, чтобы просто поместить данные в базу данных.

1 голос
/ 19 мая 2010

Я когда-то работал над приложением финансовой отчетности, где обновления были запрещены, все изменения были создание новых записей с обновленными данными. Это должно было обеспечить полную историю изменений всех изменений учетной записи.

0 голосов
/ 19 мая 2010

В рамках, который мы используем, нет Create, только CreateOrUpdate. Мы никогда не сталкивались с делом, в котором нам нужно было просто создать.

Другими словами, это то, что было предложено, поэтому мы пошли с ним, и это еще не подвело нас. Системе два года, около 300 столов.

В нашем случае мы не меняем первичные ключи, и если первичный ключ соответствует существующей строке, это не так.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...