Is it better to have separate Create and Edit actions or combine Create and Edit into one?

Question

We are using ASP.NET MVC 2 with a Controller/View Presentation Layer and Model consisting of A Business Logic Layer, Data Access Layer [Stored Procedures and classes/methods to talk to the stored procedures].

In the business layer and above for most purposes Edit seems to be capable of representing both the creation of an object and the editing of an object. This coincides well with our Repository Design Pattern that defines a "Save" method. We can simply check in the stored procedure if the ID is 0 and then create a new object if it is 0 otherwise we can just update the existing object, since the category id should match one.

The primary point of discussion is if it makes the most sense to split Edit that includes Creation into it's separate parts of Create and Edit beyond the DAL layer.

An obvious example can be shown as routes:

Create - http://someurl/somearea/edit/0

Edit - http://someurl/somearea/edit/254

vs.

Create - http://someurl/somearea/create

Edit - http://someurl/somearea/edit/254

Are there any established standards or best practices in regard to this?

I know this is a small detail, but I think it's logistically an important one.

• Adam Lear: I personally think separate Create and Edit actions is a much cleaner (and possibly easier to maintain) implementation.
• CaffGeek: One method in the DAL, two for the API if it makes sense.
• maz3tt: Well from my point of view seperate create and edit come naturally to mvc and going with that approach gives lot of advantage of using the mvc to its fullest and that should be everybody aim.

Answer 1

I would definitely say that there's worth in separating Create/Edit, if not for obeying the single responsibility principle.

One could claim that there's better SEO in having the correct action in the url as well.

Not separating the two would also make the code harder to unit test.

A new programmer reading the code would probably not find the code very intuitive having to create objects in an "edit" method, it just doesn't make sense semantically. I can however sympathize with the Save() method in the DAL.

Thinking about it, I can't really see the benefits of putting it all in a Edit method.

Answer 2

I usually prefer to create one Save method in the DAL, but actually implement the Create/Edit/Delete separately.

For example, my Save method would check the Object State, and call the Create/Edit/Delete method depending on what is needed

switch(obj.State)
{
 case ObjectState.New:
 CreateObject(obj);
 break;
 case ObjectState.Modified:
 UpdateObject(obj);
 break;
 case ObjectState.Deleted:
 DeleteObject(obj);
 break;
}

This allows me to just call one generic method for saving any object, but still keeps the implementation of each (Create, Edit, Delete) separated.

• NoChance: How could you tell its a delete?
• Rachel: Usually my objects have a State property. For example, clicking the Delete button would mark the object as Deleted, then call SaveChanges()