L'utilizzo dei getter in XAML ha un aspetto negativo?

Question

L'utilizzo dei getter in XAML ha un aspetto negativo?

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

3

Recentemente ho avuto una discussione con un collega sull'uso dei getter (senza setter) in classi del modello di visualizzazione usate da XAML.

Esempio:

public string FullName
{
   get
   {
      return $"{FirstName} {LastName}";
   }
}
//call OnPropertyChanged("FullName") when setting FirstName or LastName

Il suo argomento era che dovresti sempre creare coppie get / set che usano un campo privato (con il setter che solleva l'evento PropertyChanged se il valore è stato effettivamente cambiato).

Esempio:

private string _fullName;
public string FullName
{
   get
   {
      return _fullName;
   }
   set
   {
      if (value != _fullName)
      {
         _fullName = value;
         OnPropertyChanged("FullName");
      }
   }
}
//Set FullName when setting FirstName or LastName

Io, d'altra parte, penso che sia corretto utilizzare i getter (che calcolano l'output al volo), a condizione che non vengano aggiornati continuamente tramite troppe chiamate PropertyChanged .

Non penso che i miei colleghi si avvicinino è male - penso che sia un lavoro molto più impegnativo che potrebbe semplicemente non essere necessario. Comunque era sicuro che il mio approccio fosse negativo e andrebbe evitato a tutti i costi.

Come esempio opposto, ho sottolineato che la classe base MVVM di DevExpress ha i metodi RaisePropertyChanged e RaisePropertiesChanged (per l'aggiornamento di più proprietà) pronti per l'uso - entrambi i quali non sarebbero necessari se tutte le proprietà fossero ottenute / set (la classe base di DevExpress espone anche un metodo SetProperty per l'uso in setter, che include anche una chiamata PropertyChanged ). La sua argomentazione era che "beh, la gente è testarda, continua a sbagliare, quindi DevExpress ha semplicemente aggiunto quei metodi per assicurarsi che le persone siano felici", che ho trovato ... strano, per non dire altro.

Quindi, qual è il risultato qui? È un cattivo progetto utilizzare i getter nei modelli di visualizzazione progettati per essere utilizzati da XAML?

EDIT: Ho dimenticato di menzionare ... il mio collega ha anche affermato che usare coppie get / set sarà sempre più veloce. Questo sembra essere vero per quanto riguarda l'aggiornamento dell'interfaccia utente, ma ha anche usato questo argomento come argomento che i getter non dovrebbero mai essere usati. L'intera discussione è iniziata quando ho avuto un po 'di problemi di prestazioni quando ho popolato una griglia di dati con più file (cioè 12k) in cui la mia VM ha utilizzato un discreto numero di getters ...

c# xaml mvvm

posta Shaamaan 03.02.2016 - 09:20

fonte

2 risposte

Leggi altre domande sui tag c# xaml mvvm

documento SRS e controllo versione Verbosità del test unitario in lingue non tipizzate

score 4 · Answer 1

Il tuo collega non è corretto.

Quando si lavora con la logica dell'interfaccia utente in MVVM, è comune avere proprietà per il binding derivate da altri dati.

In questi casi, non si desidera creare un altro membro privato, che aggiunge semplicemente un punto di errore senza alcun beneficio.

Nota a margine:

Se stai utilizzando C # 6, invece delle stringhe codificate puoi fare

OnPropertyChanged(nameof(FullName));

In questo modo, riceverai un errore del compilatore se cambi il nome della proprietà FullName ma dimentichi di aggiornare le chiamate corrispondenti a OnPropertyChanged.

score 3 · Answer 2

I getter come il tuo collega si aspetta, sono un odore di codice. Sono comunque lì solo per problemi di linguaggio. Quello che stanno facendo è esporre una variabile privata. Per essere onesti, potresti anche accedere direttamente alla variabile privata se questo è tutto ciò che stai utilizzando getter e tagliare uno strato di middleman.

Originariamente i linguaggi OO supportavano l'uso di metodi accessor (ad esempio getter e setter) poiché intendevano eseguire la convalida e altre logiche su ogni get e set. Ha anche nascosto i dettagli di implementazione interna dell'utente della classe, in modo da poter esporre FullName, e se successivamente hai modificato gli interni per memorizzare nome e cognome, è possibile aggiornare il getter senza modificare i client che utilizzano la classe. (e per espandere ulteriormente, quando estendi la tua classe per gestire l'iniziale centrale, anche questo può essere fatto senza dover aggiornare ogni chiamante)

Ora nel tempo, i generatori di codice come Devexpress e VS hanno aggiunto scorciatoie per aiutare, permettendoti di dichiarare una variabile privata e di digitare automaticamente il boilerplate per scrivere gli accessor. Sfortunatamente, alcune persone pensano che, poiché ciò accada, l'accessor boilerplated è quello che dovresti usare. È pazzesco che le persone non pensino da sole e siano discese in un atteggiamento da setta cargo per la codifica.

Ci sono articoli sul web che descrivono come dovresti progettare classi, che dicono che se tutto quello che stai facendo è esporre una variabile come getter, allora non hai in realtà progettato nulla.

E infine, se memorizzi due volte gli stessi dati (nome completo e nome e cognome), inizi a fare casino, dato che dovrai sempre fare un sacco di aggiornamenti ogni volta che uno dei 3 cambi .