Best practices για WPF/MVVM

[dios231]

Ξεκινάω τα πρώτα μου βήματα για C# και μαθαίνω WPF/MVVM και άλλα τέτοια ωραία πραματάκια

 

Ένα από τα πράγματα που με δυσκόλεψαν στο WPF είναι πως όλα αυτά τα concepts όπως data binding, commands, data contentx κτλ θα μπορέσουν να δέσουν σε μια εφαρμογή  όμορφα και ωραία. Όταν άρχισα να γράφω τις πρώτες γραμμές κώδικα γίνονταν ένας χαμός, dependencies μεταξύ των κλάσεων απο εδώ και από εκεί, tight coupling, πείραζα κάτι σε μια μέθοδο χαλούσε κάτι άλλο και γενικά υπήρχαν αρκετές ενδείξεις κακού κώδικα.

 

Το πρώτο πράμα που έκανα ήταν να βρω που υπάρχει το "bootstrap"  της εφαρμογής και με έναν DI container να κάνω το wiring. Βρήκα πως αυτό μπορεί να υλοποιηθεί με το να γίνει override η μέθοδος OnStartup στο APP.cs. Απέφυγα πάση θυσία να γράψω κώδικα στο code-behind του View, η μόνη γραμμή κώδικα που έγραψα στο view ήταν στον Constructor ώστε να δηλώσω το data contex για το ViewModel. 

 

Όσον αφορά τα commands, δεν ήθελα να χρησιμοποιήσω κάποιο framework όπως το prism μιας και που ότι έκανα το έφτιαχνα για να μάθω οπότε για κάθε command υπάρχει και το αντίστοιχο property στο ViewModel όπου δείχνει σε μια  delegate και με την κατάλληλη υλοποίηση στις μεθόδους Execute/CanExecute του ViewModel  γίνεται το command. Αυτό με βοήθησε για και στα tests όπου με ένα απλό BaseCommand.Execute() μπορούσα να κάνω test to ViewModel.

 

Το μόνο που με προβληματίζει είναι αν όλα τα παραπάνω θεωρούνται σωστά. Εσείς τι practices χρησιμοποιείτε  στις εφαρμογές σας; Ρωτάω διότι σε πολλά articles στο SO αλλά και γενικά είδα πραματάκια που δεν μου πολυ άρεσαν όπως κώδικας στο code behind του View, χρήση service locator αντί για dependency injection κτλ. 

[Papakaliati]

Ξεκινάω τα πρώτα μου βήματα για C# και μαθαίνω WPF/MVVM και άλλα τέτοια ωραία πραματάκια

 

Ένα από τα πράγματα που με δυσκόλεψαν στο WPF είναι πως όλα αυτά τα concepts όπως data binding, commands, data contentx κτλ θα μπορέσουν να δέσουν σε μια εφαρμογή  όμορφα και ωραία. Όταν άρχισα να γράφω τις πρώτες γραμμές κώδικα γίνονταν ένας χαμός, dependencies μεταξύ των κλάσεων απο εδώ και από εκεί, tight coupling, πείραζα κάτι σε μια μέθοδο χαλούσε κάτι άλλο και γενικά υπήρχαν αρκετές ενδείξεις κακού κώδικα.

 

Το πρώτο πράμα που έκανα ήταν να βρω που υπάρχει το "bootstrap"  της εφαρμογής και με έναν DI container να κάνω το wiring. Βρήκα πως αυτό μπορεί να υλοποιηθεί με το να γίνει override η μέθοδος OnStartup στο APP.cs. Απέφυγα πάση θυσία να γράψω κώδικα στο code-behind του View, η μόνη γραμμή κώδικα που έγραψα στο view ήταν στον Constructor ώστε να δηλώσω το data contex για το ViewModel. 

 

Όσον αφορά τα commands, δεν ήθελα να χρησιμοποιήσω κάποιο framework όπως το prism μιας και που ότι έκανα το έφτιαχνα για να μάθω οπότε για κάθε command υπάρχει και το αντίστοιχο property στο ViewModel όπου δείχνει σε μια  delegate και με την κατάλληλη υλοποίηση στις μεθόδους Execute/CanExecute του ViewModel  γίνεται το command. Αυτό με βοήθησε για και στα tests όπου με ένα απλό BaseCommand.Execute() μπορούσα να κάνω test to ViewModel.

 

Το μόνο που με προβληματίζει είναι αν όλα τα παραπάνω θεωρούνται σωστά. Εσείς τι practices χρησιμοποιείτε  στις εφαρμογές σας; Ρωτάω διότι σε πολλά articles στο SO αλλά και γενικά είδα πραματάκια που δεν μου πολυ άρεσαν όπως κώδικας στο code behind του View, χρήση service locator αντί για dependency injection κτλ.

 

Μπορείς να κοιτάξεις να αφαιρέσεις τελείως το code behind, και χρησιμοποιοντας datatemplates να πας σε view model first τεχνικές . Βέβαια θεωρώ ότι όλα αυτά μικρή σημασία έχουνε, άμα είναι πολύ πιο εύκολο και ενδεχομένως σύντομο να κάνεις κάτι με code behind, δεν είναι μεμτο.

 

Έχω δει εξαιρετικά δυσαναγνωστες λύσεις, άμα με code behind κάποιος μπορεί να καταλάβει τον κώδικα σου 5 φορές πιο εύκολα άποτι χωρίς, τότε μάλλον χάνει την αξία του.

[Apoll]

Ξεκινάω τα πρώτα μου βήματα για C# και μαθαίνω WPF/MVVM και άλλα τέτοια ωραία πραματάκια

 

Ένα από τα πράγματα που με δυσκόλεψαν στο WPF είναι πως όλα αυτά τα concepts όπως data binding, commands, data contentx κτλ θα μπορέσουν να δέσουν σε μια εφαρμογή  όμορφα και ωραία. Όταν άρχισα να γράφω τις πρώτες γραμμές κώδικα γίνονταν ένας χαμός, dependencies μεταξύ των κλάσεων απο εδώ και από εκεί, tight coupling, πείραζα κάτι σε μια μέθοδο χαλούσε κάτι άλλο και γενικά υπήρχαν αρκετές ενδείξεις κακού κώδικα.

 

Το πρώτο πράμα που έκανα ήταν να βρω που υπάρχει το "bootstrap"  της εφαρμογής και με έναν DI container να κάνω το wiring. Βρήκα πως αυτό μπορεί να υλοποιηθεί με το να γίνει override η μέθοδος OnStartup στο APP.cs. Απέφυγα πάση θυσία να γράψω κώδικα στο code-behind του View, η μόνη γραμμή κώδικα που έγραψα στο view ήταν στον Constructor ώστε να δηλώσω το data contex για το ViewModel. 

 

Όσον αφορά τα commands, δεν ήθελα να χρησιμοποιήσω κάποιο framework όπως το prism μιας και που ότι έκανα το έφτιαχνα για να μάθω οπότε για κάθε command υπάρχει και το αντίστοιχο property στο ViewModel όπου δείχνει σε μια  delegate και με την κατάλληλη υλοποίηση στις μεθόδους Execute/CanExecute του ViewModel  γίνεται το command. Αυτό με βοήθησε για και στα tests όπου με ένα απλό BaseCommand.Execute() μπορούσα να κάνω test to ViewModel.

 

Το μόνο που με προβληματίζει είναι αν όλα τα παραπάνω θεωρούνται σωστά. Εσείς τι practices χρησιμοποιείτε  στις εφαρμογές σας; Ρωτάω διότι σε πολλά articles στο SO αλλά και γενικά είδα πραματάκια που δεν μου πολυ άρεσαν όπως κώδικας στο code behind του View, χρήση service locator αντί για dependency injection κτλ. 

 

Όταν έγραφα WPF πριν 6-8 χρόνια, σχεδόν ελάχιστο ήταν το code behind. Μόνο μία εφαρμογή χρειάστηκα λίγο παραπάνω κώδικα, λόγο της αρχιτεκτονικής της και των πολλών bubble events που χρειαζόμουν να χειριστώ, και το ότι επικοινωνούσε με VB6 κώδικα του server σε web classes και όχι WCF. (και κάμποσα network services για να πέρνει φωτογραφίες,και στοιχεία από lasers, weighbridges, groundloops κ.α)

 

Το 90% των εφαρμογών σε WPF, δεν χρειάζονται code behind και δουλεύεις με datatemplates όπως είπε και ο Παπακαλιάτης. Αυτός άλλωστε είναι και ο ορισμός του MVVM.

[dios231]

Το code-behind αν έχω καταλάβει καλά χρησιμοποιείται μόνο όταν θες να κάνεις πόλη εξειδικευμένα γραφικά όπως animations, 3d κτλ. Αυτό νομίζω πέρα του ότι γίνεται καλύτερη εφαρμογή του mvvm βοηθάει και στα tests του viewmodel.

 

Επίσης πως ακριβώς κάνετε το wiring μεταξύ view -viewmodel στις εφαρμογές σας?

[defacer]

Στη σωστή κατεύθυνση είσαι απ' ότι λες.

 

Ένα πράγμα πάντως να έχεις υπόψη: μη μαστιγώνεις παράλογα τον εαυτό σου για να μηδενίσεις το codebehind. Γενικά ναι, η ιδέα είναι να μην υπάρχει, και φυσικά αν κάνεις κάτι εκτός codebehind τότε de facto είναι επαναχρησιμοποιήσιμο which is good κλπ κλπ. Αλλά στην τελική όταν θες να παράγεις αποτέλεσμα (vs όταν κάνεις ακαδημαϊκές ασκήσεις) όλα είναι εργαλεία και πρέπει να χρησιμοποιούνται εκεί που βολεύει. Δε θέλω βέβαια να πω κάνε τη δουλειά σου αβέρτα codebehind έτσι;

 

Το wiring έχω δει να το δείχνουν πολλές φορές σε παράδειγμα να το κάνει ο container μόνος του αλλά προσωπικά αυτό μου φαινόταν κάπως άμπαλο και περιοριστικό -- μπορείς να το κάνεις manually εκεί που δημιουργείς νέο view (μέσα σε κάποιο command προφανώς), έτσι κι αλλιώς για μία γραμμή μιλάμε και στις δύο περιπτώσεις.

[Papakaliati]

Συμφωνω με defacer, και προσθετω συγκεκριμενα οτι το να πειραζεις πχ Datagrid ειναι πολλες φορες πιο ευκολο να το κανεις με code behind, παρα στο view model.

Γενικα παντως οτι εχει σχεση με UI συμπεριφορα δεν εχει καμια δουλεια στο Viewmodel, αλλα στο code behind εφοσων και δεν γινεται μονο με xaml code.

 

  Προσφατα επεσα σε μια τετοια περιπτωση ξανα, και εχω να πω οτι το μερικες φορες το να προσπαθεις να μην παραβιασεις τους mvvm κανονες οδηγει σε δυσαναγνωστο behαβολο κωδικα. Αφου παιδευομουνα για καμια ωρα, αποφασισα οτι απλα ειναι αμπαλο, και το εκανα σε 5 λεπτα σε code behind με πολυ ποιοτικοτερο αποτελεσμα. 

 

 

Το code-behind αν έχω καταλάβει καλά χρησιμοποιείται μόνο όταν θες να κάνεις πόλη εξειδικευμένα γραφικά όπως animations, 3d κτλ. Αυτό νομίζω πέρα του ότι γίνεται καλύτερη εφαρμογή του mvvm βοηθάει και στα tests του viewmodel.

Επίσης πως ακριβώς κάνετε το wiring μεταξύ view -viewmodel στις εφαρμογές σας?

 

Το να χρησιμοποιεις IOC για 5-10 views πραγματικα ειναι κατι σαχλο. Απο εκει και περα αποφασιζεις και κανεις. Στοχος παντα πρεπει ναναι να μπορει ενας τριτος να καταλαβει τι εχεις κανει χωρις υπερπροσπαθειες.

[dios231]

Η αληθεια ειναι οτι τον κωδικα στο code-behind το ειχα στο μυαλο σαν κατι που οδηγει σε ακαμπτο κωδικα. Δεν μου αρεσε οπως το εβλεπα και πραγματικα με δυσκολευε πολυ στο να τον κατανοησω. Καταλαβαινω αυτο που λετε και εχω αρχισει να εξεταζω στο μυαλο μου διαφορετικα σεναρια υλοποίησης.

 

Παντως θα ηθελα να μαθω για πιο λογο ενας κωδικας που κακα τα ψεματα θα λεγαμε οτι δεν παραβιαζει καποιο απο τα SOLID principles θεωρειται σαχλο ενω καποιες πιο quick and dirty τεχνικες θεωρουνται καλυτερες? Ξανα λεω οτι αυτο το ποστ για να μαθω το ξεκινησα και οχι για να παρουσιασω το αγιο δισκοποτηρο του WPF. Η αληθεια ειναι οτι ενας κωδικας τον οποιο τον γραφεις μια φορα και απο εκει και περα δεν ασχολησε μαζι του ολα τα παραπανω ισως να ειναι οντως υπερβολη,  οι λυσεις που θα δωσεις μικρη σημασία εχουν. Όμως κωδικας στον οποιο οχι μονο δεν τον παρατας αλλα ασχολουντε και παραπανω απο ενα ατομο μαζι του νομιζω οτι θελει λιγο παρα πανω προσοχη και λιγο περισσοτερη σκεψη στο τι γραφεις. Αν και πολλες φορες οταν στα ατομα μιας ομαδας δεν μιλάνε ολα την ιδια "γλωσσα" ισως και τοτε υπερβολικες υλοποιησεις να δυσκολευουν παρα να βοηθανε.

[defacer]

αλλα στο code behind εφοσων και δεν γινεται μονο με xaml code.

 

Ε, όλα είναι σχετικά. Άμα αρχίσεις τα triggers και τα attached behaviors να δεις τι καλά που γίνονται όλα "μόνο με xaml" 

 

 

Παντως θα ηθελα να μαθω για πιο λογο ενας κωδικας που κακα τα ψεματα θα λεγαμε οτι δεν παραβιαζει καποιο απο τα SOLID principles θεωρειται σαχλο ενω καποιες πιο quick and dirty τεχνικες θεωρουνται καλυτερες? Ξανα λεω οτι αυτο το ποστ για να μαθω το ξεκινησα και οχι για να παρουσιασω το αγιο δισκοποτηρο του WPF. Η αληθεια ειναι οτι ενας κωδικας τον οποιο τον γραφεις μια φορα και απο εκει και περα δεν ασχολησε μαζι του ολα τα παραπανω ισως να ειναι οντως υπερβολη,  οι λυσεις που θα δωσεις μικρη σημασία εχουν. Όμως κωδικας στον οποιο οχι μονο δεν τον παρατας αλλα ασχολουντε και παραπανω απο ενα ατομο μαζι του νομιζω οτι θελει λιγο παρα πανω προσοχη και λιγο περισσοτερη σκεψη στο τι γραφεις. Αν και πολλες φορες οταν στα ατομα μιας ομαδας δεν μιλάνε ολα την ιδια "γλωσσα" ισως και τοτε υπερβολικες υλοποιησεις να δυσκολευουν παρα να βοηθανε.

 

Είσαι πολύ γενικός και δε νομίζω ότι υπάρχει εδώ κάποια ερώτηση που μπορεί να απαντηθεί.

[Papakaliati]

Ε, όλα είναι σχετικά. Άμα αρχίσεις τα triggers και τα attached behaviors να δεις τι καλά που γίνονται όλα "μόνο με xaml" 

 

 Ολα πιθανως να γινονται, αλλα δεν ειναι και η ιδανικη λυση να εχεις 2 μιλια xaml κωδικα

Απο την φυση ειναι καπως φλιαρη ;p 

[dios231]

ΟΚ ας γινω λιγο πιο συγκεκρημενος. Ο @papakaliatis πιο πανω αναφερει πως IOC για λιγα views ειναι υπερβολη και ισως οδηγει σε χειροτερα αποτελεσματα απο οτι δεν χρησιμοποιουσες.  Και ρωταω για πιο λογο να ισχυει κατι τετοιο? Αφου αυτα τα patterns για να βοηθησουν υπαρχουν και οχι για να δυσκολεύουν τα πραγματα.

[Papakaliati]

ΟΚ ας γινω λιγο πιο συγκεκρημενος. Ο @papakaliatis πιο πανω αναφερει πως IOC για λιγα views ειναι υπερβολη και ισως οδηγει σε χειροτερα αποτελεσματα απο οτι δεν χρησιμοποιουσες.  Και ρωταω για πιο λογο να ισχυει κατι τετοιο? Αφου αυτα τα patterns για να βοηθησουν υπαρχουν και οχι για να δυσκολεύουν τα πραγματα.

 

 

Για τον ιδιο λογο που οταν πας για να κυνηγησεις μπεκατσες, δεν παιρνεις μαζι σου RPG και ΑΚ-47. 

 

Επιπλεον, δεν χρειαζεσαι ΙΟC Container για να εφαρμοσεις dependency injections. 

Σε projects με λιγα views, θα κανεις μονος σου τα wirings του Injection, για να αποφυγεις να χρησιμοποιησεις ενα τριτο module, οπως ενα container. 

[dios231]

Νομιζω πως υπηρξε μια παρερμηνεια  σε αυτα που εγραψα και ισως μην ημουν πολυ κατανοητος. 

 

Προφανως για το depedency injection δεν ειναι υποχρεωτικη η χρηση καποιου container. To wiring μπορει να γινει και με το "χερι" στην αρχη της εφαρμογης οπου και δημιουργειται το object graph. Το βασικο μου αγχος ηταν αν ολα αυτα εχουν χωρο στο WPF/MVVM και αν οδηγουν σε καλυτερα η χειροτερα αποτελεσματα.

 

Απο οτι καταλαβα πιο πολυ αυτο εξαρταται απο την φυση της εφαρμογης που πας να φτιαξεις οχι απο καθ΄ αυτα τα patterns (οπως ισχυει και με ολα τα patterns) .

 

Τελος παντων νομιζω πως το υπεραναλυσαμε, εγω τις πηρα τις απαντησεις μου και εμαθα αυτα που ηθελα

[dios231]

Επαναφερω το topic για να ρωτησω κάτι.

 

Μπορεί κάποιος να μου εξηγήσει τι είναι ακριβώς το design time και ποια προβλήματα με αυτό μπορεί να λύσει ένας viewmolellocator?