Απ'ότι έχω καταλάβει ψάχνοντας στο Internet, πρόκειται για μεγάλο βραχνά! Το σενάριο έχει ως εξής και είναι απλό: ρύθμιση παραμέτρων μέσω ενός παραθύρου. Πατάς κουμπάκι, βγαίνει παραθυράκι, κάνεις τις ρυθμίσεις σου και πατάς ΟΚ. Στις παλιές, καλές ημέρες, τούτο φαινόταν εύκολο. Μέχρι που ήρθε ο διάολος το MVVM και γυρίσανε τα πάνω κάτω. Ο ένας προτείνει μια DialogService, ο άλλος Behaviors, ο τρίτος μιλάει για dependency injection, σκάει μύτη και ο απίθανος που λέει - για όνομα του Χριστού και της Παναγίας! - "μην χρησιμοποιείς παράθυρα διαλόγου!". Κάνε subscribe σε events στο ViewModel, πήγαινε Αθήνα-Θεσσαλονίκη μέσω Βλαδιβοστόκ, χόρεψε τον χορό της βροχής...κι όλα αυτά γιατί κάποιος είχε την φαεινή ιδέα ότι το code behind βλάπτει, τζιζ, φτου κακά και μακριά από μας! Click events? Παλιατζούρες και αρχαία ιστορία! Commands και ξερό ψωμί! ShowDialog()? Ούτε καν! Κάνε ένα interface, στρώσε μια κλάση που θα το κάνει implement, ρίξε και ένα τάμα στην Παναγία της Τήνου. Γιατί βρε παιδιά; Πρέπει να έχω τριανταπέντε Bachelor στην Πληροφορική και να μιλάω C# αντί για ελληνικά στον περιπτερά της γειτονιάς μου;
Μακρυγορω και με συγχωρείτε. Το ερώτημά μου: μπορεί κάποιος να μου δώσει μια απλή λύση για το παραπάνω πρόβλημα;

ΥΓ: Για να προλάβω αυτόν που θα ρωτήσει "γιατί ταλαιπωρείσαι με το MVVM αφού είσαι νιόκος και δεν καταλαβαίνεις υψηλά νοήματα όπως delegation και dependencies" η απάντηση είναι η εξής: γιατί θέλω να τα καταλάβω!

Επειδή το ίδιο πρόβλημα είχα, έχω και λογικά ο κάθε ένας, άποψή μου είναι να διαλέξεις ένα τρόπο από αυτούς που ανέφερες να μείνεις σε αυτόν σε όλα τα projects σου έτσι ώστε αν στην πορεία βρεις κάτι άλλο να μπορείς εύκολα να αλλάξεις. Εγώ προτίμησα την λογική των Services.  Με DI και το service να υλοποιεί ένα Interface όλα είναι εντάξει. Φυσικά άλλοι προτιμούν άλλο τρόπο και σεβαστό.

 

Απ'όλα τα πιθανά σενάρια τα οποία έχω δει εκεί έξω, η λύση της Service μου φάνηκε κι εμένα σαν η πιο προσιτή. Το κόλλημά μου είναι όμως ότι - όπως και για το MVVM γενικά - δεν υπάρχει κάποιος στάνταρ τροπος υλοποίησης που να μπορώ να ακολουθήσω. Ένας μπούσουλας είναι αυτό που λείπει για να μου λύσει τα χέρια. 

Εξαρτάται τι θες να κάνεις, εξαρτάται, εξαρτάται, εξαρτάται. Καταρχήν να πω ότι αν δεν σκοπεύεις να κάνεις unit testing ή να κάνεις sharing τον XAML κώδικα με κάποιον designer ή να υποστηρίζει η εφαρμογή σου skins, τότε το MVVM σε βάζει να πηδήξεις πολλά στεφάνια (και μερικά από αυτά φλεγόμενα) χωρίς να καρπώνεσαι τα καλά του. Αν θες να μπορείς να κάνεις τα προηγούμενα θα πρέπει να πληρώσεις το τίμημα. Από εκεί και πέρα, υπάρχουν dialogs και dialogs. Αν πρόκειται για κάποιο πολύ απλό dialog (τύπου confirm ή exception), τότε το κέρδος του να το κάνεις με τον κλασικό τρόπο είναι συνήθως μεγαλύτερο από το να υλοποιήσεις έναν ολόκληρο μηχανισμό. Αν πρόκειται για ένα σύνθετο dialog, τότε υπάρχουν αρκετές λύσεις και φτάνουμε στο "εξαρτάται, εξαρτάται, εξαρτάται". Εδώ είναι που ξεφεύγεις από την πεπατημένη και δεν έχεις πλέον "μπούσουλα" καθώς εμφανίζονται διάφορες επιλογές η κάθε μία με τα πλεονεκτήματα και τα μειονεκτήμα της. Ένα άλλο πράγμα που μπαίνει στο "εξαρτάται" είναι αν χρησιμοποιηείς ήδη κάποιο framework. Αν πχ στην εφαρμογή σου δεν παίζεις με DI ή δεν παίζεις με MEF, καλύτερα να μην υλοποιήσεις μια λύση που έχει DI ή MEF μόνο και μόνο για τα dialogs. Το βασικό πρόβλημα με τα dialogs στο MVVM είναι ότι με τον κλασικό τρόπο υπάρχει μεγάλη περίπτωση να δημιουργηθούν memory leaks λόγω των event handlers που παραμένουν στη μνήμη και γι αυτό οι πιο περίπλοκες υλοποιήσεις χρησιμοποιούν weak references. Και για να φτάσουμε στο δια ταύτα, θα σου πρότεινα να εξετάσεις την τεχνική του mediator pattern πάνω στην οποία βασίζεται ο Messenger του MVVM Light.

---

Vir prudens non contra ventum mingit

Αυτό το "εξαρτάται" είναι που με έχει φάει! Ναι, μιλάμε για σύνθετα παράθυρα διαλόγου. Ένα απλό MessageBox, πάει στον κόρακα, θα το βγάλω στο ViewModel - αν και νευριάζω λίγο που δεν δέχεται styling - και ας ωρύονται οι απανταχού ένθερμοι αμύντορες. Όπως είπα όμως, πρόκειται για παράθυρο ρυθμίσεων, κι εκεί είναι που αρχίζεις τα Lexotanil. Το MVVM Light δεν το έχω εξετάσει, αλλά ψιθυρίζεται ότι δεν προτείνεται για αρχάριους. Θα το εξετάσω όμως.
Από κει και πέρα, όλα τούτα αποτελούν προσωπική περιπέτεια. Δεν υπάρχει κάποια ομάδα γύρω μου, δεν υπάρχει Project Manager στον σβέρκο μου σαν τον Χάροντα με την δρεπάνα, δεν υπάρχουν deadlines. Άρα δεν έχω καμία όρεξη να μπλέξω με unit tests, με skins και άλλα ωραία. Γηράσκω αεί διδασκόμενος, όμως, και το MVVM μοιάζει αναπόφευκτο, τουλάχιστον until the next big thing. Μαζοχισμός; Ίσως. Μισή ντροπή δική μου, μισή στην Κίνα βρίσκεται.

Δεν νομίζω ότι θα έπρεπε να αντιμετωπίζεις το ζήτημα από αυτή την σκοπιά - το dialog box είναι μια εφεύρεση που υπήρξε στην ροή εργασίας με τα Windows Forms για να διακόψει την ροή του χρήστη και να του εισάγει μια επείγουσα διαδικασία. Είναι κουτό να προσπαθήσεις να κάνεις το ίδιο σε άλλες τεχνολογίες. Και καλά σε WPF και Silverlight στο desktop σε παίρνει να το κάνεις. Στο web, τα pop-ups κάποτε κυριαρχούσαν, τώρα και για ένα alert() σκέφτεσαι δύο φορές πριν το βάλεις από τα pop-up blockers, και αποφασίζεις ότι θα το κάνεις με jQuery ή μια παρόμοια τεχνολογία.

Συνεχίζοντας τον ισχυρισμό μου, τον επεκτείνω στα κινητά τηλέφωνα, που λόγω της μικρής οθόνης, δεν σκέφτεσαι καν να "πετάξεις" ένα dialog πάνω από μία οθόνη - οδηγείς το χρήστη σε νέα οθόνη, για να κάνει την εργασία. Από ότι έχει φανεί, οι χρήστες είναι "ευέλικτοι" και δεν έχουν πρόβλημα με αυτή την νέα διαδικασία. Το πρόβλημα όμως φαίνεται να είναι στον προγραμματιστή που δεν είναι αποφασισμένος να το αποδεχτεί...

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Σίγουρα έχεις δίκιο όταν λες ότι, ανάλογα με την τεχνολογία που χρησιμοποιείς, πρέπει να προσαρμόζεις ανάλογα τον τρόπο σκέψης σου. Ας μου επιτραπει όμως να αντιστρέψω λίγο τον ισχυρισμό σου. Πρέπει κι εγώ ν'αρχίζω να γράφω τις desktop εφαρμογές μου με την λογική του web ή των smartphones; Ανέκαθεν οι one-window εφαρμογές - που συνήθως δούλευαν με workspaces ή όπως αλλιώς το ονομάζει κανείς - φάνταζαν κουλές. Ακόμα και τώρα, εφαρμογές που διατυμπανίζουν ότι "όλα γίνονται σε ένα παράθυρο", κάποια στιγμή θα αναγκαστούν να πετάξουν ένα messagebox ή ενα παράθυρο διαλόγου. Είμαι της άποψης ότι ο κάθε χώρος έχει την λογική του. Όπως δεν μπορείς - και δεν πρέπει - να προγραμματίζεις σε Android σα να είσαι στο desktop, έτσι δεν μπορείς - και δεν πρέπει - να προγραμματίζεις στο desktop σα να είσαι σε Android.