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


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.

  • 4
    I personally think separate Create and Edit actions is a much cleaner (and possibly easier to maintain) implementation.
    – Adam Lear
    Aug 29, 2011 at 13:50
  • 1
    One method in the DAL, two for the API if it makes sense.
    – CaffGeek
    Aug 29, 2011 at 14:32
  • 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.
    – maz3tt
    Aug 29, 2011 at 15:16

2 Answers 2


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.


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

    case ObjectState.New:
    case ObjectState.Modified:
    case ObjectState.Deleted:

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

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.