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.

I regularly come across situations where I need to Add or Edit an item, and sometimes I use separate methods for Add and Edit, and other times I combine them into a single method.

Is one method preferred over the other? If so, why?

public void AddItem()
{
    ShowEditingPopup(new Item(), "Add Item");
}

public void EditItem(Item item)
{
    ShowEditingPopup(item, "Edit Item");
}

OR

public void EditItem(Item item)
{
    ShowEditingPopup(
        (item ?? new Item()), 
        string.format("{0} Item", (item == null ? "Add " : "Edit "))
    );
}

where ShowEditingPopup is defined as

public void ShowEditingPopup(object popupDataContext, string popupTitle)
{
    PopupDataContext = popupDataContext;
    PopupTitle = popupTitle;
    IsPopupVisible = true;
}

Edit: Just to clarify, I am not Saving the item, I am opening it for Editing. I almost always implement a generic Save method for saving to the database

Edit #2: Edited code samples so they more accurately reflect the sort of situation I am referring to

share|improve this question
    
Minor quibble - if you are going to combine, use a proper name for the method EditOrAddItem, instead of just EditItem. –  Oded Sep 23 '11 at 18:52
    
@Oded I just use SaveItem ... it applies for both. –  AJC Sep 23 '11 at 18:54
    
@AJC - fair enough. However, the example still has EditItem. –  Oded Sep 23 '11 at 18:55
1  
More of a matter of choice than anything else....Will like to see the answers though –  Pankaj Upadhyay Sep 23 '11 at 18:56
1  
@FrustratedWithFormsDesigner There was a recent one, but it dealt with saving changes to a repository, in which case I think a Save method is perfectly valid programmers.stackexchange.com/q/104404/1130 –  Rachel Sep 23 '11 at 18:58

4 Answers 4

Think about your context for a second... There is no distinction between Adding a new element or editing an existing one. You just SaveChanges(). The individual element state tell the context whether its a new element being added or an existing one being edited.

EDIT: Ok... Well in that case, I do have separate Controller Actions (MVC3) for each action, however, only 1 view...

share|improve this answer
    
I am not saving the object, I am opening it in a new window for Editing. (I do have a generic Save method for saving the object back to the database though) –  Rachel Sep 23 '11 at 19:00
    
@Rachel view edit... –  AJC Sep 23 '11 at 19:51
    
This question was prompted because the code I am working with usually calls ShowPopup(popupContent, popupTitle);, and I was curious if there was a reason to create separate calls showing a new item or an existing item, or to do both in the same method. –  Rachel Sep 23 '11 at 20:11
    
@Rachel I can't find a reason not to combine the calls... However it is a personal choice... If you want to keep them separated or mix them. Like I said, in my case, I use separate calls, but the same UI for both. –  AJC Sep 23 '11 at 20:17
    
+1 for different actions but same view. Think of the sites that you visit that have the best usability..most of them use the same screen for creating/editing items, unless there are very specific business conditions enabled/shown when doing either action. –  silverCORE Oct 11 '11 at 18:49

Let's say I'm adding or editing a Person entity. I would almost always have two models to handle the add/edit processes:

  • AddPersonModel
  • EditPersonModel

They would almost always inherit from a common abstract base class:

  • AddEditPersonModelBase

So the base class might have an abstract Commit method, which the derived classes override in order to either new up a new Person entity, or to save the changes to the existing Person entity.

The business logic that's common to both adding and editing goes in the base class (for instance, for editing addresses), but there's always a little bit of business logic that's different if you're adding or editing, and those go in the subclasses. For instance, you might want to assign them a unique incrementing ID number, but you don't actually create it until you save the entity. In that case, only your EditPersonModel has that property.

Similarly, you'd have separate Views (and ViewModels) for adding or editing a Person, but it would make sense to have both add and edit variants inherit from the same base class because a lot of it would be common.

share|improve this answer
    
In this case, and in most cases I have done recently, both Adding and Editing use the exact same form. I am using WPF / MVVM, and the UI is a generic DataTemplate for the object, while the ViewModel for the object knows how to handle it based on it's state. –  Rachel Sep 23 '11 at 19:02
    
@Rachel - in MVVM parlance, you either new up an AddPersonViewModel (which doesn't take a Person in the constructor) or an EditPersonViewModel (which does take an existing Person in the constructor). Whichever one gets created gets set as the Window's DataContext. When WPF sees one of those in the layout, it goes looking for a DataTemplate for that ViewModel and applies it automatically. Both AddPersonViewModel and EditPersonViewModel inherit from a common base class with the common logic between them in it. For instance, an ICommand to save. Save button binds to that. –  Scott Whitlock Sep 23 '11 at 19:10
    
@Rachel - You can have a common DataTemplate that binds to either the add or edit ViewModel (by binding to the base class), or you can add a new DataTemplate that binds to a child class, if one or both need to have different Views. –  Scott Whitlock Sep 23 '11 at 19:13
    
Usually I just have a PersonViewModel which accepts a Person object in the constructor. I usually create small apps and often don't see a need for separate Views/ViewModels unless there is a large difference between a new object and an existing one. It is that kind of situation that prompted my question. –  Rachel Sep 23 '11 at 19:15

I personally tend to follow the principals of being semantic. This means that I usually don't provide a all-in-one edit form. In other words, users usually don't want to edit the entire information of an entity. Rather their edit process is more semantic and can be classified. For example, for user entity, people usually edit passwords and edit profile. Thus, I make two functions for edit like:

public bool EditPassword(string userName)
{
    // code here
}

public bool EditProfile(Profile newProfile)
{
    // code here    
}

Or, users usually edit an article in these ways:

public bool PutArticleIntoCategories(int articleId, List<Category> categories)
{

}

public bool EditArticleSummary(int articleId, string newSummary)
{

}

In brief, I usually create a all-in-one creation form, but I tend to use small, chunked edit forms for each semantic edit operation. Thus, I usually don't merge them. However, this doesn't mean that you can't merge them. Whenever you want to provide a fat, big edit form which resembles creation form, I think merging can work better.

share|improve this answer

This is a matter of how well you understand Single Responsibility Principle. It would be more cleaner and easier to read, understand, and maintain if the responsibilities are decoupled in to seperate methods/actions. However, this from the coding perspective.

If I had to pick one approach out of your examples, I would go for the first approach.

The user's perspective depends on how easy is to add new item or edit an existing item (number of clicks is one way I measure) and probably to follow few golden rules.

If I had to implement the functionality (UI/Form), I would have a single form when add and edit both have same fetures, and two seperate forms when they differ.

share|improve this answer

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.