views:

75

answers:

3

Recently someone stated that they thought all Creates should be CreateOrUpdates. Instinctively i thought bad, but now I am trying to find out if I have any grounds.

Situation

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

or

   interface IService{
       void CreateOrUpdate(Object a);
  }

My first thought is if you implemented everything CreateOrUpdate then you have no control if someone accidentally sends you wrong data, or concurrency issues where someone changes a "primary" field right before you call update....

But if you remove those cases, are there any other cons?

A: 

In the framework that we use, there is no Create, only CreateOrUpdate. We've never run into a case where we needed just Create.

In other words, it's what was offered, so we went with it, and it hasn't failed us yet. System is two years old with around 300 tables.

In our case, we don't change primary keys, and if the primary key matches an existing row, it's not wrong.

Marcus Adams
+1  A: 

I once worked on a financial reporting application where updates were forbidden, all changes were creation of new records with updated data. This was to provide a complete revision history of all account changes.

Dour High Arch
+1, though as a modification I'd suggest a single allowed update: setting an "end generation" field on an existing record to indicate that a new row has superseded it.
Edmund
+2  A: 

It seems pretty simple to me: if you are concerned about accidental record creation use the two methods. If you aren't concerned use one.

And if you don't know if you should be concerned or not, you arent concerned. Go with one method.

Maybe that's overly simplistic, but usually the goal is just to get the data into the database.

Bryan Oakley