Quando è preferibile combinare la funzionalità Aggiungi / Modifica e quando tenerle separate?

Question

Quando è preferibile combinare la funzionalità Aggiungi / Modifica e quando tenerle separate?

#1 da (2 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)

8

Mi imbatto regolarmente in situazioni in cui ho bisogno di aggiungere o modificare un elemento, e a volte uso metodi separati per aggiungere e modificare, e altre volte li combino in un unico metodo.

Un metodo è preferito rispetto all'altro? Se sì, perché?

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 "))
    );
}

dove ShowEditingPopup è definito come

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

Modifica: giusto per chiarire, non sto salvando l'oggetto, lo sto aprendo per l'editing. Ho quasi sempre implementato un metodo di salvataggio generico per il salvataggio nel database

Modifica n. 2: esempi di codice modificati in modo da riflettere più accuratamente il tipo di situazione a cui mi riferisco

coding-style

posta Rachel 23.09.2011 - 20:44

fonte

4 risposte

Leggi altre domande sui tag coding-style

Dove posso trovare un algoritmo per creare anaglifi 3D usando un'immagine di mappa di profondità? tabelle senza classi possibili con Datamapper?

score 2 · Answer 1

Pensa al tuo contesto per un secondo ... Non c'è alcuna distinzione tra l'aggiunta di un nuovo elemento o la modifica di uno esistente. Hai appena SaveChanges() . Il singolo stato dell'elemento indica al contesto se è stato aggiunto un nuovo elemento o se ne sta modificando uno esistente.

EDIT: Ok ... Beh, in quel caso, ho separato Controller Actions (MVC3) per ogni azione, tuttavia, solo 1 vista ...

score 0 · Answer 2

Diciamo che sto aggiungendo o modificando un'entità Person . Avrei quasi sempre due modelli per gestire i processi di aggiunta / modifica:

AddPersonModel
EditPersonModel

Avrebbero quasi sempre ereditato da una classe base astratta comune:

AddEditPersonModelBase

Quindi la classe base potrebbe avere un metodo Commit astratto, che le classi derivate sovrascrivono per rinnovare una nuova entità Person , o per salvare le modifiche all'entità Person esistente.

La logica aziendale che è comune sia all'aggiunta che alla modifica va nella classe base (ad esempio, per modificare gli indirizzi), ma c'è sempre un po 'di logica di business che è diversa se si aggiungono o si modificano, e quelli vanno in le sottoclassi. Ad esempio, potresti voler assegnare loro un numero ID incrementale univoco, ma in realtà non lo creerai finché non salvi l'entità. In questo caso, solo la tua EditPersonModel ha quella proprietà.

Allo stesso modo, avresti viste separate (e ViewModels) per l'aggiunta o la modifica di Person , ma avrebbe senso avere entrambe le varianti di aggiunta e modifica ereditate dalla stessa classe base perché molto sarebbe comune .

score 0 · Answer 3

Personalmente tendo a seguire i principi di essere semantico . Ciò significa che di solito non fornisco un modulo di modifica tutto in uno. In altre parole, gli utenti di solito non vogliono modificare l'intera informazione di un'entità . Piuttosto il loro processo di modifica è più semantico e può essere classificato. Ad esempio, per entità utente , le persone di solito modifica le password e modifica profilo . Pertanto, creo due funzioni per la modifica come:

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

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

Oppure, gli utenti di solito modificano un articolo in questi modi:

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

}

public bool EditArticleSummary(int articleId, string newSummary)
{

}

In breve, di solito creo un modulo di creazione tutto in uno, ma io tendo ad usare moduli di modifica piccoli e bocciati per ogni operazione di modifica semantica. Pertanto, di solito non li unisco. Tuttavia, questo non significa che non puoi unirli. Ogni volta che si desidera fornire una forma di modifica grossa, grande che assomiglia al modulo di creazione, penso che la fusione può funzionare meglio.

score 0 · Answer 4

Questa è una questione di quanto bene comprendi Principio di responsabilità singola . Sarebbe più più pulito e più facile leggere, capire e mantenere se le responsabilità sono disaccoppiate in metodi / azioni separati. Tuttavia, questo dal punto di vista della codifica.

Se dovessi scegliere un approccio dai tuoi esempi, sceglierei l'approccio primo .

La prospettiva dell'utente dipende da quanto è facile aggiungere un nuovo elemento o modificare un elemento esistente (il numero di clic è un modo che io misuro) e probabilmente seguire poche regole d'oro.

Se dovessi implementare la funzionalità (UI / Form), avrei un singolo modulo quando aggiungere e modificare hanno entrambi gli stessi fetti e due moduli separati quando differiscono.