La produzione ReactiveUI è pronta?

Question

Ho esaminato la possibilità di utilizzare l'interfaccia utente reattiva nel codice di produzione. Alcune delle funzionalità sono davvero allettanti, ma temo di dover dipendere da questa libreria. Questi includono:

1. Denominazione e convenzioni Whacky. Ad esempio, i membri protetti iniziano con lettere minuscole e il metodo RaiseAndSetIfChanged dipende dal membro privato che inizia con un trattino basso. Capisco che Paul Betts (autore di ReactiveUI) abbia uno sfondo rubino, quindi credo che sia da lì che deriva la strana denominazione. Tuttavia, ciò causerà un problema reale, poiché la denominazione standard (come per Stylecop) viene applicata durante il mio progetto. Anche se non fosse applicato, sarei preoccupato per la conseguente incoerenza nel nominare ciò che causerà.
2. Mancanza di documentazione/campioni. C'è della documentazione e un campione solitario. Tuttavia, la documentazione è solo una serie di (vecchi) post del blog e l'esempio è basato su V2 della libreria (è ora su V4).

3. Design strano, in parti. Ad esempio, la registrazione è astratta in modo da non assumere una dipendenza da un framework di registrazione specifico. Giusto. Tuttavia, poiché utilizzo log4net (e non NLog) mi servirà il mio adattatore. Penso che mi richiederà di implementare IRxUIFullLogger, che ha un crapload metrico di metodi in esso (ben oltre 50). Avrei pensato che un approccio migliore sarebbe quello di definire un'interfaccia molto semplice e quindi fornire metodi di estensione all'interno di ReactiveUI per facilitare tutti i sovraccarichi necessari. Inoltre, c'è questa strana interfaccia IWantsToRegisterStuff da cui dipende l'assembly NLog, su cui non potrò dipendere (perché è un'interfaccia interna). Spero di non averne bisogno ...

   In ogni caso, la mia preoccupazione è il design generale della libreria. Qualcuno è stato morso da questo?

4. Sto già utilizzando MVVM Light ampiamente. So che Paul ha fatto un post sul blog in cui spiega che è possibile utilizzare entrambi tecnicamente, ma la mia preoccupazione riguarda maggiormente la manutenibilità. Sospetto che sarebbe orribilmente difficile confonderlo tra loro nel codice base.

Qualcuno ha esperienza pratica con l'interfaccia utente reattiva in produzione? In tal caso, sei in grado di dissipare o risolvere uno dei miei dubbi sopra citati?

Answer 1

Andiamo attraverso il vostro preoccupazioni pezzo per pezzo:

# 1. "Whacky naming and convention."

Ora che ReactiveUI 4.1+ ha CallerMemberName, non c'è bisogno di utilizzare le convenzioni a tutti (e anche allora, si può ignorare loro tramite RxApp.GetFieldNameForPropertyFunc). Basta scrivere una proprietà come:

int iCanNameThisWhateverIWant; 
public int SomeProperty { 
    get { return iCanNameThisWhateverIWant; } 
    set { this.RaiseAndSetIfChanged(ref iCanNameThisWhateverIWant, value); } 
} 

2 #. La mancanza di documentazione/campioni

Questo è legittimo, ma ecco alcune altre docs/campioni:

• http://docs.reactiveui.net/ (questa è la documentazione ReactiveUI ufficiale, un work in progress, ma sicuramente in cui si desidera iniziare)
• https://github.com/reactiveui/ReactiveUI.Samples
• https://github.com/reactiveui/RxUI_QCon
• https://github.com/play/play-windows

# 3. "Avrei pensato un approccio molto migliore sarebbe quella di definire un'interfaccia molto semplice e quindi fornire metodi di estensione all'interno ReactiveUI per facilitare tutti i sovraccarichi necessari"

Implementare IRxUILogger invece, ha una scarsa due metodi :) ReactiveUI riempirà il resto IRxUIFullLogger è lì solo se ne hai bisogno.

"Inoltre, c'è questa strana interfaccia IWantsToRegisterStuff"

Non è necessario sapere su questo :) Questo è solo per trattare con ReactiveUI stesso inizializzazione in modo che non si deve avere il codice standard.

4. "Ho il sospetto che sarebbe stato terribilmente confusa avendo entrambi mescolati nella propria base di codice."

Non proprio. Pensala come "MVVM Light with SuperPowers".

Answer 2

Lo uso in produzione e finora RxUI è stato perfettamente stabile. L'applicazione ha avuto problemi di stabilità, alcuni hanno a che fare con EMS, altri con un gestore di UnhandledException che causava più problemi di quanti ne risolvesse, ma non ho avuto alcun problema con la parte ReactiveUI dell'applicazione. Tuttavia, ho avuto problemi riguardanti l'ObservableForProperty che non ha funzionato affatto, che potrei aver usato in modo errato e ha funzionato in modo coerente (non corretto) nel mio codice di test e nell'interfaccia utente in fase di esecuzione.

-1. Paul spiega che _Upper è dovuto all'utilizzo del reflection per accedere al campo privato della tua classe.È possibile utilizzare un blocco, come di seguito per affrontare i messaggi StyleCop e ReSharper, che permette di generare facilmente (dal ReSharper SmartTag)

/// <summary>The xxx view model.</summary> 
    public class XXXViewModel : ReactiveObject 
    { 
    #pragma warning disable 0649 
    // ReSharper disable InconsistentNaming 

    [SuppressMessage("StyleCop.CSharp.NamingRules", 
     "SA1306:FieldNamesMustBeginWithLowerCaseLetter", 
     Justification = "Reviewed. ReactiveUI field.")] 
    private readonly bool _IsRunning; 

    [SuppressMessage("StyleCop.CSharp.NamingRules", 
     "SA1306:FieldNamesMustBeginWithLowerCaseLetter", 
     Justification = "Reviewed. ReactiveUI field.")] 
    private string _Name; 
    .... 

o cambia le proprietà dalla piena

/// <summary>Gets or sets a value indicating whether is selected.</summary> 
    public bool IsSelected 
    { 
     get { return _IsSelected; } 
     set { this.RaiseAndSetIfChanged(x => x.IsSelected, value); } 
    } 

le sue parti componenti quali

/// <summary>Gets or sets a value indicating whether is selected.</summary> 
    public bool IsSelected 
    { 
     get { return _isSelected; } 
     set 
     { 
      if (_isSelected != value) 
      { 
       this.RaisePropertyChanging(x => x.IsSelected); 
       _isSelected = value; 
       this.RaisPropertyChanged(x=>x.IsSelected); 
      } 
     } 
    } 

Questo modello è utile anche quando in realtà non si fornisce un "semplice" di accesso struttura, ma può richiedere una variante più derivata dove s il valore di un valore interessa più altri.

-2. Sì, la documentazione non è l'ideale, ma ho scoperto che dopo Rx, la raccolta dei campioni RxUI era abbastanza semplice. Ho anche notato che i salti da 2 a 4 sembrano essere tutti accompagnati dalle modifiche per supportare Windows 8/Windows 8 Phone e, avendo rilevato ReactiveUI per un'app di Windows Store, il supporto di DotNet 4.5 è eccellente. L'uso di [CallerName] ora significa che semplicemente questo.RaiseAndSetIFChanged (valore) non necessita dell'espressione.

-3. Non ho alcun feedback sul lato del logging come non ho scelto di usarlo.

-4. Non ho nemmeno mescolato e abbinato con altri quadri.

C'è anche un elenco di altri contributori a ReactiveUI 4.2 a http://blog.paulbetts.org/index.php/2012/12/16/reactiveui-4-2-is-released/, incluso Phil Haack.

Answer 3

Sto rispondendo come qualcuno che ha utilizzato ReactiveUI in alcuni sistemi di produzione, ha avuto problemi con il modo in cui RxUI fa cose e ha inviato patch per provare a risolvere i problemi che ho avuto.

Disclaimer: Non uso tutte le funzionalità di RxUI. Il motivo per cui non sono d'accordo con il modo in cui tali funzionalità sono state implementate. Illustrerò i miei cambiamenti mentre vado.

1. Denominazione. Pensavo che anche questo fosse strano. Questo finì per essere una delle caratteristiche che non uso davvero. Io uso PropertyChanged.Fody per intrecciare la notifica di modifica utilizzando AOP. Di conseguenza le mie proprietà sembrano proprietà auto.

2. Doco. Sì, potrebbe esserci di più. Soprattutto con le parti più recenti come il routing. Questo probabilmente è un motivo per cui non uso tutto RxUI.

3. Registrazione. Ho avuto problemi con questo in passato. Vedi pull request 69. Alla fine della giornata vedo RxUI come un quadro molto opinato. Se non sei d'accordo con questa opinione, puoi suggerire dei cambiamenti, ma questo è tutto. L'opinione non è cattiva.

4. Uso RxUI con Caliburn Micro. CM gestisce posizione View-ViewModel e binding, Screen e Conductors. Non uso il binding della convenzione di CM. RxUI gestisce i comandi e il codice INPC ViewModel e mi consente di reagire alle modifiche delle proprietà utilizzando Reactive anziché gli approcci tradizionali. Tenendo separate queste cose, trovo molto più facile mescolare le due cose insieme.

Qualcuno di questi problemi ha qualcosa a che fare con l'essere pronti per la produzione? No. ReactiveUI è stabile, ha una base utenti di dimensioni decenti, i problemi vengono risolti rapidamente nel google group e Paul è ricettivo alla discussione.