Argumentos en contra de Crear o actualizar

Question

Recientemente, alguien declaró que pensaban que todo lo creado debería ser CreateOrUpdates. Instintivamente pensé mal, pero ahora estoy tratando de averiguar si tengo algún motivo.

Situación

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

o

interface IService{ 
     void CreateOrUpdate(Object a); 
    } 

Mi primer pensamiento es que si ha implementado todo CreateOrUpdate entonces usted no tiene control si alguien accidentalmente le envía datos erróneos, o problemas de concurrencia en la que alguien cambia un " campo "primario" justo antes de llamar a la actualización ....

Pero si elimina esos casos, ¿hay algún otro inconveniente?

Answer 1

Me parece muy simple: si le preocupa la creación de registros accidentales, utilice los dos métodos. Si no está preocupado, use uno.

Y si no sabe si debería preocuparse o no, no está preocupado. Ve con un método

Quizás eso es demasiado simplista, pero por lo general el objetivo es solo obtener los datos en la base de datos.

Answer 2

En el marco que usamos, no hay Crear, solo CreateOrUpdate. Nunca nos hemos encontrado con un caso en el que necesitáramos solo Crear.

En otras palabras, es lo que se ofreció, así que lo hicimos, y aún no nos ha fallado. El sistema tiene dos años con alrededor de 300 tablas.

En nuestro caso, no cambiamos las claves principales, y si la clave primaria coincide con una fila existente, no está mal.

Answer 3

Una vez trabajé en una aplicación de informes financieros donde las actualizaciones estaban prohibidas, todos los cambios fueron creación de nuevos registros con datos actualizados. Esto fue para proporcionar un historial de revisión completo de todos los cambios en la cuenta.