¿Cuándo se prefiere combinar la funcionalidad Agregar / Editar y cuándo mantenerlos separados?

Regularmente encuentro situaciones en las que necesito agregar o editar un elemento, y a veces uso métodos separados para agregar y editar, y otras veces los combino en un solo método.

¿Se prefiere un método sobre el otro? Si es así, ¿por qué?

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

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

O

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

donde ShowEditingPopupse define como

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

Editar: solo para aclarar, no estoy guardando el elemento, lo estoy abriendo para editarlo. Casi siempre implemento un método Save genérico para guardar en la base de datos

Edición n. ° 2: ejemplos de código editados para que reflejen con mayor precisión el tipo de situación a la que me refiero

Piense en su contexto por un segundo ... No hay distinción entre Agregar un nuevo elemento o editar uno existente. Usted acaba SaveChanges(). El estado del elemento individual le dice al contexto si se está agregando un nuevo elemento o si se está editando uno existente.

EDITAR: Ok ... Bueno, en ese caso, tengo acciones de controlador separadas (MVC3) para cada acción, sin embargo, solo 1 vista ...

Digamos que estoy agregando o editando una Personentidad. Casi siempre tendría dos modelos para manejar los procesos de agregar / editar:

• AddPersonModel
• EditPersonModel

Casi siempre heredarían de una clase base abstracta común:

• AddEditPersonModelBase

Por lo tanto, la clase base podría tener un Commitmétodo abstracto , que las clases derivadas anulan para crear una nueva Personentidad o para guardar los cambios en la Personentidad existente .

La lógica de negocios que es común tanto para agregar como para editar va en la clase base (por ejemplo, para editar direcciones), pero siempre hay un poco de lógica de negocios que es diferente si está agregando o editando, y esas van en las subclases. Por ejemplo, es posible que desee asignarles un número de identificación incremental único, pero en realidad no lo crea hasta que guarda la entidad. En ese caso, solo tu EditPersonModeltiene esa propiedad.

Del mismo modo, tendría Vistas (y ViewModels) separadas para agregar o editar un Person, pero tendría sentido que las variantes de agregar y editar hereden de la misma clase base porque muchas de ellas serían comunes.

Personalmente, tiendo a seguir los principios de ser semántico . Esto significa que generalmente no proporciono un formulario de edición todo en uno. En otras palabras, los usuarios generalmente no desean editar toda la información de una entidad . Más bien, su proceso de edición es más semántico y puede clasificarse. Por ejemplo, para una entidad de usuario , las personas generalmente editan contraseñas y editan el perfil . Por lo tanto, hago dos funciones para editar como:

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

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

O, por lo general, los usuarios editan un artículo de estas formas:

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

}

public bool EditArticleSummary(int articleId, string newSummary)
{

}

En resumen, generalmente creo un formulario de creación todo en uno, pero tiendo a usar formularios de edición pequeños y fragmentados para cada operación de edición semántica. Por lo tanto, generalmente no los combino. Sin embargo, esto no significa que no pueda fusionarlos. Siempre que desee proporcionar un formulario de edición grande y grueso que se parezca al formulario de creación, creo que la fusión puede funcionar mejor.

Esta es una cuestión de qué tan bien entiendes el Principio de responsabilidad única . Sería más limpio y fácil de leer, comprender y mantener si las responsabilidades se desacoplan para separar los métodos / acciones. Sin embargo, esto desde la perspectiva de la codificación.

Si tuviera que elegir un enfoque de sus ejemplos, elegiría el primer enfoque.

La perspectiva del usuario depende de lo fácil que sea agregar un nuevo elemento o editar un elemento existente (el número de clics es una forma de medir) y probablemente seguir algunas reglas de oro.

Si tuviera que implementar la funcionalidad (UI / Formulario), tendría un solo formulario cuando agregar y editar ambos tengan las mismas características, y dos formularios separados cuando difieren.