Απαραιτητη η γνωση XAML για αναπτυξη εφαρμογων WPF;

[geo1st487]

Ποσο απαραιτητη ειναι η γνωση XAML για αναπτυξη εφαρμογων WPF με C#;

Βλεπω οτι ο κωδικας XAML γραφεται αυτοματα οταν βαζεις controls πανω στη φορμα αλλα δεν ξερω κατα ποσο χρειαζεται η γνωση XAML.

Ευχαριστω

[defacer]

Τόσο απαραίτητη όσο η γνώση HTML για την ανάπτυξη εφαρμογών web: 100%.

[geo1st487]

Τόσο απαραίτητη όσο η γνώση HTML για την ανάπτυξη εφαρμογών web: 100%.

 

Γιατι;

[defacer]

Δεν είμαι σίγουρος πώς να σου απαντήσω δεδομένου του παραλληλισμού που ήδη έκανα, νομίζω ότι θα έπρεπε να ήταν αρκετός. 

 

1. Η XAML είναι ένας πολύ ευκολότερος τρόπος να φτιάξεις UI ή τμήματα αυτού απ' ότι αν έγραφες το ίδιο πράγμα σε κώδικα (code-behind που λένε).
2. Είναι ένας τρόπος που προσφέρεται για επεξεργασία από προγράμματα όπως visual designers (σε αντίθεση με τον κώδικα που κατα κανόνα μόνο από ανθρώπους και τον compiler είναι επεξεργάσιμος).
3. Σαν μια αυτο-επιβεβαιούμενη προφητεία: είναι πολύ χρήσιμη γενικά, άρα χρησιμοποιείται πολύ, άρα θα βρεις μπροστά σου πολύ πράγμα που θα είναι γραμμένο σε XAML, άρα πρέπει να την καταλαβαίνεις για να αποκομίσεις ώφελος από αυτό, άρα είναι πολύ χρήσιμη και ειδικά για σένα.

[migf1]

Ποσο απαραιτητη ειναι η γνωση XAML για αναπτυξη εφαρμογων WPF με C#;

Βλεπω οτι ο κωδικας XAML γραφεται αυτοματα οταν βαζεις controls πανω στη φορμα αλλα δεν ξερω κατα ποσο χρειαζεται η γνωση XAML.

Ευχαριστω

Δεν είναι απαραίτητη, αλλά βοηθάει πάρα πολύ στο να διαχωρίζεις τη λογική από το UI του προγράμματος. Έτσι μπορείς να αλλάζεις την εμφάνιση του UI χωρίς να πειράζεις καθόλου τη λογική του κώδικα.

 

Δες επίσης το MV-VM design pattern:

1. http://blog.lab49.com/archives/2650

2. http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

[παπι]

Δεν είναι απαραίτητη, αλλά βοηθάει πάρα πολύ στο να διαχωρίζεις τη λογική από το UI του προγράμματος. Έτσι μπορείς να αλλάζεις την εμφάνιση του UI χωρίς να πειράζεις καθόλου τη λογική του κώδικα.

 

Δες επίσης το MV-VM design pattern:

1. http://blog.lab49.com/archives/2650

2. http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

Δεν εχει να κανει με λογικη κλπ, εχει να κανει με τo visual tree

[defacer]

Δεν εχει να κανει με λογικη κλπ, εχει να κανει με τo visual tree

 

Διόρθωση: με το logical tree. Κατά τα άλλα σχετικά με την παράθεση από migf1 που έκανες:

 

Τι προσφέρει και τι δεν προσφέρει η XAML

 

Η XAML δε σου δίνει τη δυνατότητα να κάνεις κάτι που δε γίνεται σε code-behind, και δεν βοηθάει από μόνη της να διαχωρίσεις οτιδήποτε. Και πριν υπάρξει XAML είχαμε τη δυνατότητα να κάνουμε ακριβώς το ίδιο πράγμα σε Windows Forms, όπου με τον visual designer κάνεις πράγματα τα οποία αποτυπώνονται με τη μορφή source code ο οποίος καλείται όταν μέσα από τον constructor του εκάστοτε control καλέσεις την InitializeComponent (πράγμα που επίσης κανονίζει ο designer για σένα).

 

Ακριβώς το ίδιο πράγμα γίνεται και σε WPF (καλείται δηλαδή μια method με το ίδιο όνομα), μόνο που ο τρόπος με τον οποίο δουλεύει είναι διαφορετικός. Επίσης διαφορετικό είναι το γεγονός πως ενώ σε Forms η InitializeComponent ονομάζεται έτσι κατα σύμβαση και η υλοποίησή της υπάρχει σε μορφή source, σε WPF αποτελεί μέρος της αρχιτεκτονικής του framework και δεν υπάρχει σε source (τη δημιουργεί ο compiler κατά τη διαδικασία του compilation της XAML). Αυτά όμως είναι τεχνικές λεπτομέρειες και δεν παίζουν ρόλο στη γενική εικόνα.

 

Όπως και να 'χει, κανένας δε σε εμποδίζει να γράψεις μόνος σου τον κώδικα για το στήσιμο του logical tree (και μόνο αυτόν!) σε codebehind, να τον βάλεις σε μια method InitializeWhatever και να καλέσεις αυτή από τον constructor αντί για την InitializeComponent. Το ίδιο πράγμα είναι με αυτό που κάνει ο compiler, απλά το κάνεις manually. Επομένως η XAML αυτή καθαυτή δε σου επιτρέπει να κάνεις κάτι που δε θα μπορούσες έτσι κι αλλιώς να κάνεις μόνος σου.

 

Το πλεονέκτημα της XAML είναι πως πρόκειται για declarative language (bullets #1 και #2 από την προηγούμενη απάντησή μου) και πως η όλη κούραση της μετατροπής από declarative σε imperative μορφή γίνεται αυτόματα από τον compiler.

 

Παραλληλίζοντας τα παραπάνω με την HTML που ανέφερα νωρίτερα, κανείς δε σε εμποδίζει αντί να γράψεις HTML να έχεις μια function η οποία θα δημιουργήσει με κατάλληλες κλήσεις στο DOM την οποιαδήποτε δομή (και βέβαια τελικό αποτέλεσμα) που επιθυμείς. Το θέμα είναι ότι στη μία περίπτωση θα γράψεις αυτό

 

<p>Hello world!</p>

 

Ενώ στην άλλη περίπτωση θα γράψεις αυτό:

 

  var p = document.createElement("p");
  var text = document.createTextNode("Hello world!");

  p.appendChild(text);
  document.body.appendChild(p);

Προφανώς δεν είναι το ίδιο από άποψη ευκολίας.

 

Σχετικά με MVVM

 

To MVVM είναι στην ουσία μια μορφή της κλασικής αρχιτεκτονικής MVP προσαρμοσμένη κατάλληλα ώστε να παίζει όμορφα με τις ιδιαιτερότητες της XAML. Είναι ένα πολύ πετυχημένο κατασκεύασμα το οποίο όταν το νιώσεις, και σε συνδυασμό με κάποιο καλό MVVM framework, σε κάνει να αισθάνεσαι ninja (εμένα τουλάχιστον).

 

Αλλά, μη κάνει κανείς το λάθος να ασχοληθεί με MVVM εκτός και αν ήδη έχει φάει τη XAML με το κουτάλι ή εκτός κι αν έχει εκτενή πείρα σε πραγματικές MVP καταστάσεις. Για να μάθεις να χρησιμοποιείς ένα τέτοιο (αρκετά αφηρημένο) εργαλείο σωστά πρέπει πρώτα να έχεις νιώσει στο πετσί σου την ανάγκη την οποία σχεδιάστηκε για να καλύψει, αλλιώς θα γελάσει και το παρδαλό κατσίκι.

[παπι]

Όπως και να 'χει, κανένας δε σε εμποδίζει να γράψεις μόνος σου τον κώδικα για το στήσιμο του logical tree (και μόνο αυτόν!) σε codebehind, να τον βάλεις σε μια method InitializeWhatever και να καλέσεις αυτή από τον constructor αντί για την InitializeComponent. Το ίδιο πράγμα είναι με αυτό που κάνει ο compiler, απλά το κάνεις manually. Επομένως η XAML αυτή καθαυτή δε σου επιτρέπει να κάνεις κάτι που δε θα μπορούσες έτσι κι αλλιώς να κάνεις μόνος σου.

 

Να γραψεις τι με κωδικα;Οκ, ενα κουμπι το γραφεις, ενα popup πχ που ειναι το 34ο παρακλαδι του window πως θα το γραψεις με κωδικα;

Θελω να πω οτι ναι μεν μπορεις να κανεις καποια πραγματα θεωτητικα, αλλα πρακτικα... Δεν.

[defacer]

Να γραψεις τι με κωδικα;Οκ, ενα κουμπι το γραφεις, ενα popup πχ που ειναι το 34ο παρακλαδι του window πως θα το γραψεις με κωδικα;

Θελω να πω οτι ναι μεν μπορεις να κανεις καποια πραγματα θεωτητικα, αλλα πρακτικα... Δεν.

 

Με πολύ κόπο και κούραση (όπως στο DOM παράδειγμα που έδωσα). Για το "πρακτικά δεν" καταλαβαίνω τι θέλεις να πεις, αλλά UI έγραφε ο κόσμος και πριν βγει η XAML και τα XML layouts του android οπότε ας μη μεγαλοποιούμε τα πράγματα.

 

Το point μου παραπάνω είναι ότι ο διαχωρισμός του Α από το Β σε επίπεδο αρχιτεκτονικής (π.χ. MVP vs αχταρμάς) είναι τελείως διαφορετικό πράγμα από τον τρόπο με τον οποίο θα υλοποιήσει κανείς το Χ (π.χ. XAML vs κώδικας C#).

[migf1]

http://stackoverflow.com/questions/1002604/xaml-or-c-sharp-code-behind

[ParhsG]

Αμφιβάλω παντως ποσο αξία εχει ολο το binding/mvvm κτλ στο wpf. Το σιγουρο ειναι πως ειναι αντιπαραγωγικό εκτος αν το δουλευεις συχνα. Επισης δεν υποστηριζεται οπως πρεπει. Δηλαδη σε ενα listbox δε μπορεις να κανεις binding με καποια λιστα εκτος αν κατσεις και βαλεις extension. Εντωμεταξυ ο αλλος που το κανει απλά θα σου λεει οτι κολοβαρας γιατι δε το κανεις απο πισω να τελιώνεις οπως ολα;

Οι περισσοτεροι παντως για να εχουν σωστα το MVVM χρησιμοποιουν και framework για αυτο. (Caliburn Micro,MVVM Light κτλ).

Χωρια που δεν εχει default τροπο για validation στις φορμες παρα εχεις καμποσες επιλογες και καμια δε δουλευει σωστα out of the box οπως σε αλλες πλατφορμες. 

Νομιζω πως αν καποιος ειναι κατω απο πιεση ή θελει απλα να δουλευει ο κωδικας και τα βρισκει * αυτα codebehind ειναι η καλυτερη λυση

[migf1]

Το link που παρέθεσα αμέσως προηγουμένως, αν κάτσει και το διαβάσει κανείς όλο, περιέχει πάρα πολλά κι ενδιαφέροντα.

 

Το resume είναι πως σε μεγάλα projects, μεσοπρόθεσμα (αφού δηλαδή έχει εκπαιδευτεί το προσωπικό) συμφέρει να διαχωρίζεις το UI από τον κώδικα τουλάχιστον σε ότι αφορά την ποιότητα και των δυο, αφού ουσιαστικά επιτρέπει να ασχολείται ένα εξειδικευμένο team για την σχεδίαση (με ελάχιστες ή καθόλου γνώσεις προγραμματισμού), κι άλλο ένα εξειδικευμένο για τον κώδικα (με ελάχιστες ή καθόλου γνώσεις σχεδιασμού).

 

Δεν είμαι σίγουρος, αλλά νομίζω πως στα 8άρια το προωθούν ακόμα περισσότερο μαζί με το Silverlight ως "ενοποιημένη" προσέγγιση.

[defacer]

Αμφιβάλω παντως ποσο αξία εχει ολο το binding/mvvm κτλ στο wpf. Το σιγουρο ειναι πως ειναι αντιπαραγωγικό εκτος αν το δουλευεις συχνα. Επισης δεν υποστηριζεται οπως πρεπει. Δηλαδη σε ενα listbox δε μπορεις να κανεις binding με καποια λιστα εκτος αν κατσεις και βαλεις extension. Εντωμεταξυ ο αλλος που το κανει απλά θα σου λεει οτι κολοβαρας γιατι δε το κανεις απο πισω να τελιώνεις οπως ολα;

Οι περισσοτεροι παντως για να εχουν σωστα το MVVM χρησιμοποιουν και framework για αυτο. (Caliburn Micro,MVVM Light κτλ).

Χωρια που δεν εχει default τροπο για validation στις φορμες παρα εχεις καμποσες επιλογες και καμια δε δουλευει σωστα out of the box οπως σε αλλες πλατφορμες.

Νομιζω πως αν καποιος ειναι κατω απο πιεση ή θελει απλα να δουλευει ο κωδικας και τα βρισκει * αυτα codebehind ειναι η καλυτερη λυση

Είναι αντιπαραγωγικό όταν το στήνεις στην αρχή από το μηδέν. Το ζήτημα είναι πως, ειδικά στον επαγγελματικό τομέα, το software το στήνεις μία φορά και μετά το συντηρείς για χρόνια. Επειδή οι πιο architected προσεγγίσεις έχουν σα στόχο να μειώσουν το κόστος συντήρησης, θέλουν να έχεις επενδύσει για να βγάλουν τα λεφτά τους (φαντάζομαι το "εκτος αν το δουλεύεις συχνά" όπως το έχεις στο μυαλό σου δεν είναι τελειώς άσχετο μ' αυτό που λέω).

 

Για το ότι δε μπορείς να κάνεις binding σε λίστα χωρίς extension δεν είμαι σίγουρος τι θέλεις να πεις -- εννοείται πως μπορείς να κάνεις binding σε λίστα. Για το ότι χρειάζεσαι MVVM framework για σοβαρή δουλειά είναι απόλυτα σίγουρο, και θα το πήγαινα ακόμα παραπέρα και θα έλεγα ότι θέλει και επιπλέον επεκτάσεις πάνω στο framework ούτως ώστε να είναι εύκολο και παραγωγικό να δουλεύεις με τον τρόπο που έχεις αποφασίσει (έχω γράψει ο ίδιος πάρα πολύ πράμα που πατάει πάνω σε extensibility points του Prism).

 

Επίσης γενικά να επαναλάβω ότι δεν είναι καλή ιδέα να κρίνουμε πράγματα τα οποία δεν έχουμε "νιώσει" (βασικά grok θέλω να πω και δε βρίσκω καλύτερη λέξη). Από το "αμφιβάλλω πόσο αξία έχει" εγώ καταλαβαίνω ότι αμφιβάλλεις επειδή δεν ξέρεις -- αν ήξερες, θα μπορούσες να πεις ότι έχει Χ αξία και Υ μειονεκτήματα και δε θα αμφέβαλλες για κάτι. Αλλά εαν δεν ξέρεις τότε γιατί προσπαθείς να βγάλεις συμπέρασμα χωρίς να μάθεις πρώτα;

 

Σχετικά με το κάτω από πίεση: όταν είσαι σε πίεση δε σε παίρνει να χρησιμοποιείς οτιδήποτε περισσότερο απ' αυτά που γνωρίζεις σαν την παλάμη του χεριού σου. Αν γνωρίζεις MVVM σ' αυτό το επίπεδο δε βλέπω το γιατί θα σε καθυστερήσει.

 

Σχετικά με το θέλει απλά να δουλεύει ο κώδικας: αν θέλεις "απλά μια σκεπή", στήνεις μια λαμαρίνα πάνω σε 4 παλούκια. Αν όμως θέλεις σπίτι πας σε χτίστη. Δεν υφίσταται σύγκριση ανάμεσα στα 2. Ιδιαίτερα όσον αφορά τον επαγγελματικό και όχι το χομπίστικο χώρο, προσωπικά αηδιάζω με το γεγονός ότι η αγορά είναι γεμάτη από ανθρώπους που αυτοαποκαλούνται επαγγελματίες αλλά στην πράξη το μόνο που έχουν μάθει ποτέ είναι το "απλά να δουλεύει ο κώδικας". Πίστεψέ με, όταν αργότερα έρθει η ώρα να γίνει ο απολογισμός αυτό το "απλά να δουλεύει" το μετανιώνουν όλοι πολύ πικρά εκτός από τον αχαρακτήριστο που έκανε τη δουλειά, πληρώθηκε και έφυγε.

 

@migf1: Καλό είναι να κρατάει κανείς και μια πισινή αν και όταν βγάζει συμπεράσματα για πράγματα στα οποία δεν έχει hands-on εμπειρία.

[migf1]

...

@migf1: Καλό είναι να κρατάει κανείς και μια πισινή αν και όταν βγάζει συμπεράσματα για πράγματα στα οποία δεν έχει hands-on εμπειρία.

Όπως για παράδειγμα κάνεις εσύ (π.χ. η C υποστηρίζει OOP);

 

Πέρα από αυτό, ούτε υποστήριξα πως είμαι XAML/WPF guru, ούτε παραπληροφόρησα τους αναγνώστες του νήματος, ούτε το έπαιξα δάσκαλος. Υπάρχει από κάποιον κάποια διαφωνία αφενός πως η XAML δεν είναι απαραίτητη για WPF programming κι αφετέρου πως είναι ένας ποιο abstract τρόπος για διαχωρισμό του UI από τον υπόλοιπο κώδικα; Διότι σε περίπτωση που δεν το έχεις αντιληφθεί, αυτό έγραψα.

 

Αν δεν υπάρχει, τότε αδυνατώ να αντιληφθώ γιατί και για ποιο πράγμα πρέπει να κρατήσω πισινή. Αν υπάρχει, lets hear it.

[defacer]

Όπως για παράδειγμα κάνεις εσύ (π.χ. η C υποστηρίζει OOP);

 

Πέρα από αυτό, ούτε υποστήριξα πως είμαι XAML/WPF guru, ούτε παραπληροφόρησα τους αναγνώστες του νήματος, ούτε το έπαιξα δάσκαλος. Υπάρχει από κάποιον κάποια διαφωνία αφενός πως η XAML δεν είναι απαραίτητη για WPF programming κι αφετέρου πως είναι ένας ποιο abstract τρόπος για διαχωρισμό του UI από τον υπόλοιπο κώδικα; Διότι σε περίπτωση που δεν το έχεις αντιληφθεί, αυτό έγραψα.

 

Αν δεν υπάρχει, τότε αδυνατώ να αντιληφθώ γιατί και για ποιο πράγμα πρέπει να κρατήσω πισινή. Αν υπάρχει, lets hear it.

 

Δεν το θεωρώ σκόπιμο να ανοίξω κουβέντα επι του θέματος, και όπως είναι φανερό πολύ άσχημα έκανα και με τα χεράκια μου έβγαλα τα ματάκια μου κάνοντας override το ignore list. Αγαπητοί ακροατές ζητούμε συγγνώμη για την αναστάτωση και επιστρέφουμε στη μόνιμη κατάσταση λειτουργίας.