È buona norma utilizzare i controlli utente per strutturare i moduli WPF anche se questi controlli utente vengono utilizzati una sola volta?

7

Sviluppo un'applicazione WPF usando MVVM e sto imparando come fare le cose meglio.

Ho un modulo WPF con selettori, due elenchi con campi di ricerca e altri elementi. Attualmente tutto è in una forma e funziona. Ma ormai la VM per quel modulo ha più di 800 linee e non è ancora finita.

Voglio strutturare meglio questo modulo e il codice. Ho pensato a regioni, file con classi parziali e controlli utente. Penso che i controlli utente siano i migliori perché incapsulano un paio di controlli e logica. Se usassi i controlli utente, la quantità di codice in quella finestra e VM verrebbe drasticamente ridotta.

Per farlo correttamente, lavoro attraverso il libro "Pro WPF 4.5 In C # 4th Edition", Capitolo 18 - Elementi personalizzati e l'esempio ColorPickerUserControl. L'esempio riguarda un selettore di colori con tre cursori e ha 150 righe di codice.

Penso di capire come funziona, ma mi sembra che la creazione di controlli utente, anche con funzionalità molto limitate come quella di quell'esempio, sia molto lavoro . Se usassi questi controlli più volte, capisco che avrebbe senso farlo. Ma se uso i controlli solo una volta e lo faccio solo per strutturare il mio modulo, allora sembra che ci sia molto lavoro per poco guadagno.

La mia domanda è: è buona norma utilizzare i controlli utente per strutturare i moduli anche se questi controlli utente vengono utilizzati una sola volta? In caso contrario, esiste un'alternativa migliore?

Modifica (non è necessario leggere, solo più informazioni): Fino ad ora non ho scritto alcun dettaglio perché volevo conoscere il principio, ma dopo aver letto la risposta interessante di 17 su 26, ecco alcuni dettagli: questo modulo serve per selezionare i titoli musicali.

  • Gruppo A: (possibile controllo utente A) riguarda il tipo di selezione come seleziona per artista o album, con o senza video, forse anno di pubblicazione, ecc.

  • Gruppo B: questo elenco contiene i nomi degli artisti che vengono filtrati in base ai criteri in A. L'utente può filtrare l'elenco, ovvero mostrare solo i nomi degli artisti che contengono "top".

  • Gruppo C: questo elenco mostra i titoli dell'artista selezionato in B utilizzando anche i criteri di A (cioè audio o video). Può essere filtrato in modo simile a B vale a dire solo i titoli contenenti "tu".

La maggior parte della logica si verifica nella VM (DataContext del modulo). Gli elenchi di A e B provengono da un database. Le liste sono filtrate e preparate per la presentazione (cioè più titoli con lo stesso nome ma in album diversi). L'utente seleziona un titolo nella lista C facendo doppio clic o trascina la selezione in un altro modulo WPF.

Quello che voglio: voglio codice leggibile in modo che io possa facilmente modificarlo. Se voglio aggiungere un altro filtro diciamo di mostrare solo artisti femminili, sarebbe bello se potessi vai al controllo utente A e aggiungi le caselle di controllo per artisti maschili e / o femminili.

Lo XAML nella forma attuale non è un problema, è ben strutturato. Ma la VM ha il codice per tutto quanto sopra. Alcune cose sono nel costruttore, alcune nella sezione comandi, alcune proprietà e campi di supporto. Posso ancora trovare le cose ora, ma penso che sarebbe meglio se il codice fosse più strutturato. Questo è il motivo per cui penso ai controlli utente.

Cerco di seguire MVVM perché penso che la logica alla base di esso abbia molto senso. Ma io non sono un seguace fanatico di alcuna pratica teorica. se posso fare qualcosa in 5 linee di CodeBehind o in 50 righe nella VM, lo farò probabilmente nel CodeBehind. La mia domanda riguarda il principio su come creare forme strutturate in WPF. Il modulo che descrivo sopra è un buon esempio, ma la risposta non dovrebbe concentrarsi su questo singolo, ma sull'idea di come strutturare i moduli WPF, cioè con (o senza) i controlli utente.

Informazioni sul motivo per cui penso che i controlli utente siano molto utili: Hanno proprietà di dipendenza, eventi indirizzati, ecc. Tutto ciò mi sembra molto più complicato delle proprietà "normali" con i campi di supporto e inotify. Ma forse devo solo abituarmi alle proprietà di dipendenza, agli eventi indirizzati, ecc.

    
posta Edgar 13.04.2018 - 10:35
fonte

3 risposte

5

Assolutamente sì. È una buona idea allo stesso modo in cui è una buona idea applicare la separazione delle preoccupazioni sulle classi per inserirne ciascuna al fine di eseguire una singola attività. Puoi avere solo un'istanza di quella classe, ma non importa. L'ottimizzazione non è in termini di prestazioni del programma, ma in termini di organizzazione e di "salute" generale del programma.

Un giorno vuoi poter tornare al tuo programma e non dover scorrere centinaia di pagine di codice, anche se è inserito in regioni (usare regioni in classi con un sacco di codice è come mettere il rossetto su un maiale , a proposito). Se mai un giorno decidessi di usarlo da qualche altra parte, puoi farlo con grazia e senza molti problemi.

Semplicemente non fare la tentazione di dare all'utente il controllo dell'accesso al modulo genitore. Se lo fai in questo modo, usa gli eventi per trasmettere informazioni al genitore, con il modulo genitore come sottoscrittore.

    
risposta data 13.04.2018 - 11:28
fonte
3

Questa è una domanda davvero difficile a cui rispondere senza vedere il codice reale. Stai anche mescolando un po 'i termini. I controlli utente non sono un mapping 1: 1 con ViewModels.

I controlli utente hanno uno scopo specifico nella vita: sono una composizione di più elementi dell'interfaccia utente utilizzati insieme come unità. I controlli utente sono sottosezioni di una vista. Questo è molto diverso da un ViewModel, che contiene la logica a cui è associata una vista.

Forse ha senso suddividere il tuo XAML in più controlli utente il tutto guidato da un singolo ViewModel. Forse ha senso suddividere il codice XAML e C # in più coppie View-VM. Forse ha senso lasciarlo come ora. Impossibile dire senza vedere il codice in questione.

Qual è il tuo obiettivo finale qui? La dimensione del codice ti causa dolore o è solo per seguire qualche pratica teorica?

Stai cercando di ridurre le dimensioni delle tue viste XAML o le dimensioni di C # ViewModels? Questi sono due compiti molto diversi nel mondo MVVM di WPF.

800 linee non sono terribilmente grandi per una VM che supporta un'interfaccia utente che ha un qualche tipo di complessità. Rompere una VM può spesso causare più problemi di quanti ne risolva. ViewModels prende decisioni come "disabilitare questa funzione quando questo altro elenco è vuoto". Cercare di suddividere quel tipo di processo decisionale su più componenti spesso non ha senso e aggiungerà semplicemente complessità al codice.

Detto questo, potrebbe esserci del lavoro che stai facendo nella VM che non ha nulla a che fare con la tua logica ViewModel e può essere facilmente partizionato nella sua stessa classe. Ciò ridurrebbe la dimensione del ViewModel senza aumentare la complessità complessiva del codice.

Credo che sia stato solo un modo molto lungo di dire "Dipende, e non possiamo dire senza vedere il codice in questione".

    
risposta data 13.04.2018 - 14:23
fonte
0

Se io, che non sapevo nulla della tua app, dovevo aggiungere un nuovo campo al campo del cognome, o cambiare l'ordine di alcuni campi ... lo troverei facile o scoraggiante?

Non mi fido delle regioni perché il compilatore non controllerà se ci si trova male nella regione sbagliata

Devi sviluppare software con l'obiettivo di rendere facile per le persone costruire su quello che hai creato.

    
risposta data 13.04.2018 - 16:05
fonte

Leggi altre domande sui tag