Άρχισα εδώ και κάποιες μέρες να ασχολούμαι με την μετατροπή μιας WebForms εφαρμογής σε ASP.net MVC. Τι μετατροπή δηλαδή, για complete rewrite πρόκειται.
Μπορώ να πω με βεβαιότητα πλέον ότι δεν πρόκειται ούτε καν να υποψιαστώ να χρησιμοποιήσω WebForms για οτιδήποτε χρειαστεί στο μέλλον. Το ASP.net MVC μου έλυσε τα χέρια στα παρακάτω προβλήματα:
1)
Page events. Στην αρχή φαίνεται ως ένα ιδιαίτερα ενδιαφέρον concept, δυστυχώς όμως σε μεγάλα projects τα πράγματα σκουραίνουν. Πέραν των τυπικών προβλημάτων που έχω δει από πρώτο χέρι (δυστυχώς), όπως για παράδειγμα το να γράφει κάποιος τρία κιλά κώδικα μέσα στα handlers, τα πράγματα μπλέκονταν όταν στο lifecycle μιας φόρμας έπρεπε να ληφθεί υπ' όψιν και το lifecycle των child controls.
Είχα αγανακτήσει με την πολυπλοκότητα κάποιων codebehind από αντίστοιχα πολύπλοκες σελίδες, και το μόνο πράγμα που μποροούσε να χειροτερέψει την κατάσταση ήταν η ανάγκη για retrofitting αλλαγών και νέων features που δεν μπορούσαν να προβλεφθούν από την αρχή.
2)
User controls. Αυτή είναι μια σχέση αγάπης και μίσους. Μου αρέσει να είμαι σε θέση να κάνω encapsulate ένα κομμάτι του logic, κι αν αυτό είναι reusable και αλλού, τόσο το καλύτερο. Βέβαια, πολλές φορές, παρά την όποια "αγάπη και προδέρμ" είχαν δείξει οι δημιουργοί των controls, είχαν κάποια προβληματάκια που ήταν επίπονο να ξεπεραστούνε, όπως για παράδειγμα η αστεία υποστήριξη για paging στο grid, η προβληματική λειτουργία του Login control με το (παλιό) url rewriting, ο μηδενικός έλεγχος της παραγόμενης HTML και ... ας μην πάμε κάν στο Control.NamingContainer και τα τεράστια html ids που παρήγαγαν.
Βέβαια, τώρα που είμαι στο Asp.net MVC bandwagon πάλι παρόμοιες τεχνικές χρησιμοποιώ, με custom HtmlHelpers και RenderAction()s, αλλά το τελικό αποτέλεσμα νομίζω είναι σαφώς καλύτερο.
3)
Μεγέθη αρχείων. Η διαφορά εδώ είναι χαοτική. Ακόμα και με την ευνόητη χρήση Gzip συμπίεσης, τα μεγέθη των αρχείων έφταναν σε απαράδεκτα νούμερα.
4)
ViewState. Ξόδεψα υπερβολικά πολύ χρόνο ώστε να φροντίσω να ελαχιστοποιήσω την χρήση του ViewState αποκλειστικά και μόνο στα σημεία που χρειάζονταν. Το αποτέλεσμα ήταν καλό, ωστόσο είμαι ιδιαίτερα ευτυχής που έχω απαλλαγεί από αυτό πλέον και μπορώ να επικεντρώσω τον χρόνο μου αλλού (και το αδερφάκι του το ControlState).
5)
1 server Html form. Στην αρχή αυτό ήταν σοκ. Επί εποχής ASP.net 1.0 μάλιστα αποτέλεσε έναν από τους λόγους που καθυστέρησα να ασχοληθώ με την ASP.net και παρέμεινα στην κλασσική ASP για ένα διάστημα. Τελικά το συνηθίσαμε, αν και είχε βέβαια κάποια χοντρά προβλήματα, όπως για παράδειγμα την συμπεριφορά του Enter (ούτε ο Community Server δεν γλύτωσε από αυτό) μέχρι να έρθει το DefaultButton...
6)
Tests; Ας μην το συζητήσουμε καν...
7)
Javascript & AJAX. Ποτέ μου δεν χώνεψα την δυσκολία του να ενσωματώσεις το jQuery ή να δουλέψω με το MS AJAX μοντέλο.
8)
Αποτέλεσμα; Χάος. Θυμάμαι το χαοτικό HTML αποτέλεσμα (πχ τα αγνώστου πηγής javascripts που αποτελούσαν μέρος του asp.net magic κ.α) λίγο πολύ απόρροια των παραπάνω.
Βέβαια, το ASP.net MVC δεν είναι τέλειο. Μακράν. Σε πολλά πράγματα οι default λύσεις δεν ταιριάζουν και πρέπει να καταφύγω σε custom υλοποιήσεις (π.χ Views σε ξεχωριστό project κοκ), ωστόσο αποτελεί μια πολύ καθαρότερη λύση η οποία σε βοηθάει στο να παράγεις πολύ πιο κατανοητό, testable και maintainable κώδικα, και νομίζω ότι μακροπρόθεσμα τα όποια πλεονεκτήματα του RAD των WebForms εξανεμίζονται ειδικά σε enterprise εφαρμογές.
Αυτή είναι η εμπειρία μου από τα τελευταία 6 χρόνια με την ASP.net, και νομίζω ότι πλέον με το MVC είναι στα καλύτερά της!
EDIT: Έπεσα σε αυτό το post:
http://blogs.msdn.com/mikeormond/archive/2009/05/06/asp-net-4-0-webforms-enhancements.aspx για τις επερχόμενες αλλαγές στο WebForms με την Asp.net 4.0. Σίγουρα αφαιρούν κάποια από τα παραπάνω παράπονά μου, αλλά και πάλι δεν τις βρίσκω ικανές να με απομακρύνουν από το ASP.net MVC.
Μην αφήνετε τα media να σας "ταΐζουν"!