Quando é preferível combinar a funcionalidade Adicionar / Editar e quando mantê-las separadas?

Eu costumo encontrar situações em que preciso adicionar ou editar um item e, às vezes, uso métodos separados para adicionar e editar; outras vezes, combino-os em um único método.

Um método é preferido em relação ao outro? Se sim, por quê?

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

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

OU

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

onde ShowEditingPopupé definido como

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

Editar: Apenas para esclarecer, não estou salvando o item, estou abrindo-o para edição. Eu quase sempre implemento um método Save genérico para salvar no banco de dados

Edição nº 2: exemplos de código editados para refletir com mais precisão o tipo de situação à qual estou me referindo

Pense no seu contexto por um segundo ... Não há distinção entre Adicionar um novo elemento ou editar um existente. Você apenas SaveChanges(). O estado do elemento individual informa ao contexto se é um novo elemento sendo adicionado ou um existente, sendo editado.

EDIT: Ok ... Bem, nesse caso, eu tenho Ações de Controlador (MVC3) separadas para cada ação, no entanto, apenas 1 visualização ...

Digamos que estou adicionando ou editando uma Personentidade. Eu quase sempre teria dois modelos para lidar com os processos de adição / edição:

• AddPersonModel
• EditPersonModel

Eles quase sempre herdariam de uma classe base abstrata comum:

• AddEditPersonModelBase

Portanto, a classe base pode ter um Commitmétodo abstrato , que as classes derivadas substituem para criar uma nova Personentidade ou salvar as alterações na Personentidade existente .

A lógica de negócios comum à adição e à edição entra na classe base (por exemplo, para editar endereços), mas sempre há um pouco de lógica de negócios que é diferente se você estiver adicionando ou editando, e elas estão nas subclasses. Por exemplo, convém atribuir a eles um número de ID incremental exclusivo, mas não o crie até salvar a entidade. Nesse caso, apenas o seu EditPersonModelpossui essa propriedade.

Da mesma forma, você teria Visualizações separados (e ViewModels) para adicionar ou editar um Person, mas não faria sentido ter tanto adicionar e editar variantes herdam a mesma classe base porque um monte de que seria comum.

Pessoalmente, tenho a tendência de seguir os princípios de ser semântico . Isso significa que normalmente não forneço um formulário de edição tudo-em-um. Em outras palavras, os usuários geralmente não desejam editar todas as informações de uma entidade . Em vez disso, o processo de edição é mais semântico e pode ser classificado. Por exemplo, para entidade de usuário , as pessoas geralmente editam senhas e perfil . Assim, eu faço duas funções para editar como:

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

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

Ou, os usuários geralmente editam um artigo das seguintes maneiras:

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

}

public bool EditArticleSummary(int articleId, string newSummary)
{

}

Em resumo, geralmente crio um formulário de criação tudo-em-um, mas costumo usar formulários de edição pequenos e em pedaços para cada operação de edição semântica. Assim, eu geralmente não os fundo. No entanto, isso não significa que você não possa mesclá-los. Sempre que você deseja fornecer um formulário grande e de edição semelhante a um formulário de criação, acho que a fusão pode funcionar melhor.

É uma questão de quão bem você entende o Princípio da Responsabilidade Única . Seria mais limpo e fácil ler, entender e manter se as responsabilidades forem dissociadas para separar métodos / ações. No entanto, isso da perspectiva da codificação.

Se eu tivesse que escolher uma abordagem dentre seus exemplos, eu usaria a primeira abordagem.

A perspectiva do usuário depende de quão fácil é adicionar um novo item ou editar um item existente (o número de cliques é uma maneira de medir) e, provavelmente, seguir algumas regras de ouro.

Se eu tivesse que implementar a funcionalidade (UI / Form), eu teria um único formulário ao adicionar e editar, ambos têm os mesmos fetures e dois formulários separados quando diferem.