Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
4  
I personally think separate Create and Edit actions is a much cleaner (and possibly easier to maintain) implementation. –  Anna Lear Aug 29 '11 at 13:50
1  
One method in the DAL, two for the API if it makes sense. –  CaffGeek Aug 29 '11 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 '11 at 15:16
add comment

2 Answers

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.

share|improve this answer
    
How could you tell its a delete? –  Emmad Kareem Aug 29 '11 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 '11 at 15:24
    
Clear - Thanks. –  Emmad Kareem Aug 29 '11 at 15:56
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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