2012-06-22 13 views
8

Mi chiedevo come si decide quando utilizzare converters e quando utilizzare triggers. Preferisco usare un trigger per le operazioni sulla GUI (come mostrare/nascondere i controlli, cambiare il loro aspetto ecc.).Devo usare il convertitore WPF o il trigger?

Qualche tempo fa ho usato un BooleanToVisibilityConverter per questo scopo, ma ora, solo che non ne hanno bisogno, faccio tutte le cose connesse alla visibility utilizzando un trigger e ho anche iniziato a pensare "qual era lo scopo di creare a BooleanToVisibilityConverter dal team MS? ". Generalmente, quando è possibile, provo a usare un modo dichiarativo per scrivere il codice - in questo esempio - XAML.

Qual è la vostra opinione?

+0

trigger vengono utilizzati per il controllo a valore singolo in cui il convertitore viene utilizzato per la conversione di tipo di valore complesso e diffrente. – JSJ

+0

Domanda simile che punta al costo delle prestazioni dei convertitori - http://stackoverflow.com/questions/5508159/datatrigger-vs-databinding-with-converter-performance-wise – akjoshi

risposta

13

Sono d'accordo con te, cerco anche di utilizzare il codice dichiarativo in XAML e preferisco Triggers anziché Converters.

Nella maggior parte degli scenari i trigger possono eseguire lo stesso lavoro di qualsiasi convertitore ma Converters può avere una logica personalizzata/aziendale come pchajer menzionato.

Una limitazione di Triggers è che Setter nel vostro DataTriggers possibile modificare solo le proprietà dei vostri elementi dell'interfaccia utente; quindi, non è possibile aggiornare la proprietà ViewModels con i trigger, ovvero con la vittoria Converters, ricordare il metodo ConvertBack.

Quindi, è possibile associare la vostra proprietà VM con i comandi Visibility utilizzando BooleanToVisibilityConverter e anche se i controlli visibility viene modificato in qualche altro modo la vostra proprietà VM viene aggiornata; in genere non è necessario è per questo che BooleanToVisibilityConverter viene sostituito da trigger.

Così, in breve -

Triggers può eseguire solo OneWay operazioni mentre Converters possibile eseguire TwoWay operazioni

+1

è * divertente * come questa risposta è quasi esattamente la stessa di [ questo altro] (http://stackoverflow.com/a/19474466/540776) – superjos

+0

@superjos Direi 'come l'altra risposta è quasi esattamente uguale a questa': D Grazie per avermelo fatto notare, mi ha fatto sorridere :) – akjoshi

+1

Sì, per rimanere in tema, ho semplicemente copiato il mio commento qua e là :) – superjos

1

È possibile ottenere la funzionalità sia per grilletto o convertitore ma dalla mia opzione seguente possibilità può essere considerato durante l'assunzione di decisioni

  1. Se si utilizza l'approccio TDD per lo sviluppo poi andare per i convertitori come si può scrivere casi di test .
  2. Se esiste una logica di business migliore per il codice di destra nel convertitore e alcuni che non possono essere raggiunti tramite trigger.
1

In aggiunta a quanto detto sopra Posso solo aggiungere:

  • I trigger a volte richiedono duplicare le cose, ad es. quando hai più di una proprietà per i trigger devi specificare ciascuna una combinazione
  • A volte hai bisogno del codice per convertire correttamente da tipo A a B, quindi devi utilizzare i convertitori. I trigger sono buoni se il valore/proprietà è già esposto dalla VM in modo che possa essere utilizzato per i trigger.
2

A mio parere, stai guardando dal basso verso l'alto e devi solo guardare dall'alto in basso.

Trigger -Quando una determinata condizione è soddisfatta che "innesca" un'esecuzione

Convertitori -Convertire tra due tipi incompatibili.

Perché abbiamo bisogno di un tipo di dati booleano quando possiamo fare la stessa funzionalità con gli interger?

0

È necessario eseguire sempre operazioni correlate all'attività negli oggetti DomainModel o almeno in un oggetto ViewModel. Fare in modo che alcune aziende lavorino nel convertitore non è una buona opzione perché i Convertitori sono progettati per convertire un valore da un tipo a un altro.

+0

Dida vedi la mia domanda? Ho scritto esplicitamente: "per operazioni su GUI (come mostrare/nascondere i controlli, cambiare il loro aspetto ecc.)". So che le opzioni relative al business devono essere controllate sull'oggetto DomainModel. –