cap
Νεοφερμένος
Ο Σωτήρης! αυτή τη στιγμή δεν είναι συνδεδεμένος. Είναι 50 ετών και επαγγέλεται Μηχανικός λογισμικού. Έχει γράψει 80 μηνύματα.
25-04-08
17:39
Θα ηθελα ομως να σε ρωτήσω κάτι μιας και γνωρίζω ελάχιστα asp.net.
Τι ειναι αυτο που δεν μπορεις να κάνεις με classic asp και το κάνεις με asp.net ?
Και δεν εννοώ ταχυτητα εγγραφής κώδικα δεν θα το δεχτώ σαν επιχειρημα γιατι απο την στιγμή που εχεις πολλές ετοιμες ρουτίνες σε .asp η ταχύτητα ειναι σχετική
Η απάντηση δεν μπορεί να είναι απλή. Εξαρτάται από τη χρήση που σκοπεύεις να κάνεις. Ειναι όμως ένα ερώτημα που έχει τεθεί πολλές φορές και από πολύ κόσμο, οπότε μπορώ να σου παραθέσω ορισμένες πολύ απλές, γενικού τύπου απαντήσεις, οι οποίες ενδεχομένως να καλύψουν την απορία σου.
Ουσιαστικά ρωτάς ποιό το όφελος από την εγκατάλειψη μιας scripting/interpreted γλώσσας και την υιοθέτηση ενός fully object-oriented, strongly-typed περιβάλλοντος ανάπτυξης. Η απάντηση, αν σκοπεύεις να αναπτύξεις ένα site με 2 δυναμικές σελίδες οπου η μια θα τραβάει πληροφορίες από ένα table μιας access και θα τις δείχνει σε ένα πινακάκι και η άλλη θα έχει μια φορμα που θα στέλνει email, είναι οτι το όφελος ειναι μηδενικό.
Αν όμως θέλεις να αναπτύξεις μια multi-user κατάσταση με membership (login κλπ), που να χρησιμοποιεί μια αρκετά περίπλοκη database, να τραβάει πράγματα και να τα δειχνει σε διάφορες μορφές και / η να επιτρέπει εξίσου εύκολα καταχωρήσεις μέσω admin εργαλείων, να υποστηρίζει scalability, να είναι εύκολη στο debugging, να είναι αρκετά εύκολο να προσθέσεις features, και το βασικότερο, να έχει αρκετό έτοιμο functionality, πολύ περισσότερο από το να έχεις ένα σκασμό έτοιμων scripts, τότε asp.net.
Η συντήρηση ενός περίπλοκου site/εφαρμογής σε asp classic είναι πολυέξοδη και χρονοβόρα. Δουλεύω ένα multi-user intranet project εδώ και αρκετά χρόνια (κληρονομημένο, όχι από την αρχή κατασκευασμένο από εμένα), το οποίο έχει ένα μέρος του ήδη κατασκευασμένο σε asp classic και ένα μέρος του σε asp.net. Η συντήρηση στο κομμάτι του asp classic απαιτεί πενταπλάσιο χρονο από την συντήρηση στο κομμάτι του asp.net.
Σιγουρα μια τόσο σύντομη και απλοϊκή απάντηση δεν "πείθει", μια και θα μπορούσα να γράφω μέρες ολόκληρες, απλά προσπαθώ να δώσω (όσο μπορώ) την κεντρική ιδέα. Η asp.net δεν απευθύνεται μόνο στον developer που θέλει να "εμπλουτίσει" ένα στατικό κατά τα άλλα site με λίγο δυναμικό περιεχόμενο (αν και εκεί ακόμα τα πράγματα είναι αρκετά γρήγορα με τη χρήση έτοιμων πραγμάτων όπως datagridview, repeaters και δεν συμμαζεύεται). Η asp.net απευθύνεται ΚΑΙ σε πιό complex καταστάσεις που ζητούν πολύ περισσότερο functionality, και εκεί τα πάει πολύ καλά.
Ολα εξαρτώνται από το υπόβαθρο του προγραμματιστή και από το σκοπό του. Τις περισσότερες φορές, αν μιλήσει κάποιος σε asp classic developers για inheritance, interfaces, delegates και δεν συμμαζεύεται, θα εισπράξει ένα "ε?" γεμάτο απορία, και δικαιολογημένα. Αν όμως έχει κάποιος χρησιμοποιήσει έστω και μια φορά στη ζωή του αυτά τα principles, τότε είναι εύκολο να καταλάβει που υπερέχει η μια κατάσταση από την άλλη.
Σταματώ εδώ, για να μην δημιουργήσω σύγχυση, και θα επανέλθω για να σου απαντήσω σε συγκεκριμένες ερωτήσεις, αν θέλεις να θέσεις κάποια.
Σημείωση: Το μήνυμα αυτό γράφτηκε 16 χρόνια πριν. Ο συντάκτης του πιθανόν να έχει αλλάξει απόψεις έκτοτε.
cap
Νεοφερμένος
Ο Σωτήρης! αυτή τη στιγμή δεν είναι συνδεδεμένος. Είναι 50 ετών και επαγγέλεται Μηχανικός λογισμικού. Έχει γράψει 80 μηνύματα.
21-04-08
12:03
Οσον αφορά στην αρχική ερώτηση του φίλου μας, έχω να παρατηρήσω τα εξής:
Ειτε έστησες IIS αφοτου έστησες το .net framework, είτε κάτι έγινε κατά τη δημιουργία των mappings των διαφόρων extensions και το .aspx extension δεν έχει γίνει mapped σωστά στο asp.net με αποτέλεσμα ο iis να το βλέπει ως απλό xml αρχείο.
Δες εδώ για πληροφορίες για το πώς να διορθώσεις αυτό το πρόβλημα:
https://support.microsoft.com/?id=306005
Ειτε έστησες IIS αφοτου έστησες το .net framework, είτε κάτι έγινε κατά τη δημιουργία των mappings των διαφόρων extensions και το .aspx extension δεν έχει γίνει mapped σωστά στο asp.net με αποτέλεσμα ο iis να το βλέπει ως απλό xml αρχείο.
Δες εδώ για πληροφορίες για το πώς να διορθώσεις αυτό το πρόβλημα:
https://support.microsoft.com/?id=306005
Σημείωση: Το μήνυμα αυτό γράφτηκε 16 χρόνια πριν. Ο συντάκτης του πιθανόν να έχει αλλάξει απόψεις έκτοτε.
cap
Νεοφερμένος
Ο Σωτήρης! αυτή τη στιγμή δεν είναι συνδεδεμένος. Είναι 50 ετών και επαγγέλεται Μηχανικός λογισμικού. Έχει γράψει 80 μηνύματα.
21-04-08
11:59
Να απαντήσω καταρχήν στο τελευταίο σου ερώτημα: Δεν υπάρχει θέμα σύγκρισης μεταξύ δύο πλατφορμών (μια και πρόκειται για πλατφόρμες, στην ουσία, και όχι απλά για γλώσσες). Η καθε μία κάνει κάποια πράγματα καλύτερα και κάποια χειρότερα, στην πραγματικότητα όμως η ποιότητα των προγραμματιστών είναι αυτή που εγγυάται την ποιότητα του αποτελέσματος.
Μια πεποίθηση που επικρατεί στην αγορά (και δυστυχώς επιβεβαιώνεται μέχρι σήμερα, από κουβέντες που έχω με εταιρίες) είναι οτι οι PHP developers στην Ελλάδα είναι λιγότερο "μπασμένοι" στο χώρο και προσπαθούν να χρησιμοποιούν πολλά έτοιμα πράγματα τα οποία στην πραγματικότητα δεν πολυγνωρίζουν πως λειτουργούν, κάτι που οδηγεί σε ερασιτεχνικά, στην καλύτερη περίπτωση, αποτελέσματα. Το φαινόμενο αυτό συντηρείται και από τις εταιρίες, οι οποίες πληρώνουν συνήθως λιγότερα για ένα php developer από ο,τι για έναν ASP.NET developer παραπλήσιου επιπέδου. Εχει βέβαια μια λογική, μια και ο asp.net developer συνήθως μπορεί να μεταπηδήσει ευκολότερα σε enterprise-level εφαρμογές ή / και win32 εφαρμογές, κάτι που αποτελεί συνήθως επένδυση για τις εταιρίες.
Στο θέμα μας τώρα (και μιλώντας κυρίως για asp.net): Οταν έχεις πολλαπλά sites σε ένα server τα οποία τρέχουν κάτω από το ίδιο process, σημαίνει συνήθως (στον IIS) οτι μοιράζονται το ίδιο application pool, ήτοι τον ίδιο χώρο μνήμης. Αυτό μειώνει τον αριθμό των processes (μονο ένα που κάνει τα πάντα), αλλά αυξάνει την πιθανότητα αν "σκάσει" ένα από τα sites να συμπαρασύρει μαζί του και όλα τα άλλα. Επίσης, αν ένα από τα sites έχει π.χ. memory leaks για κάποιο λόγο δεν έχεις κανένα έλεγχο στο πόση μνημη δεσμεύει και πόση μνήμη αφήνει ελεύθερη στα υπόλοιπα. Εκεί περιλαμβάνονται και σενάρια DoS.
Με πολλαπλά application pools έχεις απόλυτο έλεγχο στο πόση μνήμη καταλαμβάνει το καθένα, έχεις έλεγχο στο πότε θα κάνει recycle ("καθαρισμό" ουσιαστικα) - μετά από ένα συγκεκριμένο αριθμό requests, όταν η μνήμη φτάσει σε κάποιο νούμερο, ακόμα και όταν η virtual memory φτάσει σε κάποιο σημείο. Φυσικά, για κάθε application pool έχεις και ένα process.
Σε production περιβάλλοντα αυτό είναι critical, μια και δεν μπορείς να αφήνεις ΕΝΑ process να παίρνει το ρίσκο να "κατεβάσει" 100 π.χ. sites αν κάτι δεν πάει καλά. Ειναι μια τακτική που την έκαναν και παλιότερα οι asp classic άνθρωποι, όλα τα sites στο default application pool. Ομως, μιλάμε για sites που δεν είχαν ιδιαίτερη περιπλοκότητα ούτε μεγάλες απαιτήσεις σε μνήμη. Αν βάλεις όμως πέντε portals σαν το e-steki, γραμμένα σε asp.net, σε ΕΝΑ application pool, τότε μοιράζεις το ρίσκο που μπορεί να έχει ένα από αυτά και στα άλλα τέσσερα. Συνεπώς, η ύπαρξη πολλαπλών processes (σαν αποτελεσμα των πολλαπλών app pools) είναι τελικά καλό πράγμα
Οσον αφορά στα com objects: Η asp πράγματι μπορεί (και το κάνει) να καλέσει διάφορα com objects. Κλασική περίπτωση το adodb.recordset που χρησιμοποιούνταν ευρέως στην asp classic. Στην asp.net, οπου όλα τα objects αποτελούν (σε μεγάλο ποσοστό τουλάχιστον) managed .net assemblies, δεν υπάρχει αυτό το θέμα πλέον. Και οχι, η άποψή μου είναι οτι δεν καθυστερεί ΑΥΤΟ την εκτέλεση των εφαρμογών και δεν αυξάνει τη μνήμη. Εμπειρική άποψη, και όχι benchmark-based βεβαια.
Τελος, να ξεκαθαρίσω για άλλη μια φορά οτι άλλο asp classic (μια τεχνολογία που έχει "φύγει" εδώ και χρόνια) και άλλο asp.net. Δεν θα μπω, λόγω έλλειψης χρόνου, σε πλεονεκτήματα και μειονεκτήματα. Εξάλλου, θα ήταν άδικο προς την php, μια και γνωρίζω πιό καλά τα πλεονεκτήματα του asp.net. Ομως, θα μπορούσα να ανταπαντώ σε κάθε πλεονέκτημα που παρατίθεται για php με ένα αντίστοιχο ή παραπλήσιο πλεονέκτημα (αν υπάρχει ) της asp.net.
Μια πεποίθηση που επικρατεί στην αγορά (και δυστυχώς επιβεβαιώνεται μέχρι σήμερα, από κουβέντες που έχω με εταιρίες) είναι οτι οι PHP developers στην Ελλάδα είναι λιγότερο "μπασμένοι" στο χώρο και προσπαθούν να χρησιμοποιούν πολλά έτοιμα πράγματα τα οποία στην πραγματικότητα δεν πολυγνωρίζουν πως λειτουργούν, κάτι που οδηγεί σε ερασιτεχνικά, στην καλύτερη περίπτωση, αποτελέσματα. Το φαινόμενο αυτό συντηρείται και από τις εταιρίες, οι οποίες πληρώνουν συνήθως λιγότερα για ένα php developer από ο,τι για έναν ASP.NET developer παραπλήσιου επιπέδου. Εχει βέβαια μια λογική, μια και ο asp.net developer συνήθως μπορεί να μεταπηδήσει ευκολότερα σε enterprise-level εφαρμογές ή / και win32 εφαρμογές, κάτι που αποτελεί συνήθως επένδυση για τις εταιρίες.
Στο θέμα μας τώρα (και μιλώντας κυρίως για asp.net): Οταν έχεις πολλαπλά sites σε ένα server τα οποία τρέχουν κάτω από το ίδιο process, σημαίνει συνήθως (στον IIS) οτι μοιράζονται το ίδιο application pool, ήτοι τον ίδιο χώρο μνήμης. Αυτό μειώνει τον αριθμό των processes (μονο ένα που κάνει τα πάντα), αλλά αυξάνει την πιθανότητα αν "σκάσει" ένα από τα sites να συμπαρασύρει μαζί του και όλα τα άλλα. Επίσης, αν ένα από τα sites έχει π.χ. memory leaks για κάποιο λόγο δεν έχεις κανένα έλεγχο στο πόση μνημη δεσμεύει και πόση μνήμη αφήνει ελεύθερη στα υπόλοιπα. Εκεί περιλαμβάνονται και σενάρια DoS.
Με πολλαπλά application pools έχεις απόλυτο έλεγχο στο πόση μνήμη καταλαμβάνει το καθένα, έχεις έλεγχο στο πότε θα κάνει recycle ("καθαρισμό" ουσιαστικα) - μετά από ένα συγκεκριμένο αριθμό requests, όταν η μνήμη φτάσει σε κάποιο νούμερο, ακόμα και όταν η virtual memory φτάσει σε κάποιο σημείο. Φυσικά, για κάθε application pool έχεις και ένα process.
Σε production περιβάλλοντα αυτό είναι critical, μια και δεν μπορείς να αφήνεις ΕΝΑ process να παίρνει το ρίσκο να "κατεβάσει" 100 π.χ. sites αν κάτι δεν πάει καλά. Ειναι μια τακτική που την έκαναν και παλιότερα οι asp classic άνθρωποι, όλα τα sites στο default application pool. Ομως, μιλάμε για sites που δεν είχαν ιδιαίτερη περιπλοκότητα ούτε μεγάλες απαιτήσεις σε μνήμη. Αν βάλεις όμως πέντε portals σαν το e-steki, γραμμένα σε asp.net, σε ΕΝΑ application pool, τότε μοιράζεις το ρίσκο που μπορεί να έχει ένα από αυτά και στα άλλα τέσσερα. Συνεπώς, η ύπαρξη πολλαπλών processes (σαν αποτελεσμα των πολλαπλών app pools) είναι τελικά καλό πράγμα
Οσον αφορά στα com objects: Η asp πράγματι μπορεί (και το κάνει) να καλέσει διάφορα com objects. Κλασική περίπτωση το adodb.recordset που χρησιμοποιούνταν ευρέως στην asp classic. Στην asp.net, οπου όλα τα objects αποτελούν (σε μεγάλο ποσοστό τουλάχιστον) managed .net assemblies, δεν υπάρχει αυτό το θέμα πλέον. Και οχι, η άποψή μου είναι οτι δεν καθυστερεί ΑΥΤΟ την εκτέλεση των εφαρμογών και δεν αυξάνει τη μνήμη. Εμπειρική άποψη, και όχι benchmark-based βεβαια.
Τελος, να ξεκαθαρίσω για άλλη μια φορά οτι άλλο asp classic (μια τεχνολογία που έχει "φύγει" εδώ και χρόνια) και άλλο asp.net. Δεν θα μπω, λόγω έλλειψης χρόνου, σε πλεονεκτήματα και μειονεκτήματα. Εξάλλου, θα ήταν άδικο προς την php, μια και γνωρίζω πιό καλά τα πλεονεκτήματα του asp.net. Ομως, θα μπορούσα να ανταπαντώ σε κάθε πλεονέκτημα που παρατίθεται για php με ένα αντίστοιχο ή παραπλήσιο πλεονέκτημα (αν υπάρχει ) της asp.net.
Σημείωση: Το μήνυμα αυτό γράφτηκε 16 χρόνια πριν. Ο συντάκτης του πιθανόν να έχει αλλάξει απόψεις έκτοτε.
cap
Νεοφερμένος
Ο Σωτήρης! αυτή τη στιγμή δεν είναι συνδεδεμένος. Είναι 50 ετών και επαγγέλεται Μηχανικός λογισμικού. Έχει γράψει 80 μηνύματα.
21-04-08
10:33
Σε αντίθεση με την php όπου για τα πάντα χρησιμοποιεί την Ram χωρίς μάλιστα να γεμίζουν το σύστημα με άχρηστα Procress, όπως η asp που για κάθε compiler χρησιμοποιεί και άλλο Procress
Αυτό το τελευταίο ομολογώ αγαπητέ οτι δυσκολεύομαι να το καταλαβω.
Το οτι ένα process (PHP) χρησιμοποιεί για τα πάντα τη RAM είναι καλό; Αν είναι έτσι όπως φαντάζομαι οτι το εννοείς, μάλλον κακό ειναι
Το οτι "η php χρησιμοποιεί τη RAM χωρίς να γεμίζει το σύστημα με άχρηστα processes" δεν καταλαβαίνω που κολλάει. Η ίδια η php είναι ένα process στο σύστημα, και ούτως η άλλως, και τα processes, άχρηστα ή χρήσιμα, τη RAM χρησιμοποιούν. Αρα το να χρησιμοποιεί κάποιος τη RAM δεν τον απαλάσσει από το να γεμίζει το σύστημα με processes. Εκτός αν κάτι άλλο εννοούσες και δεν το κατάλαβα.
"Η asp για κάθε compiler χρησιμοποιεί και άλλο process" - Μιλάς για asp classic ή για asp.net; Γιατί στην asp classic έχουμε interpretation και όχι compilation. Διαφορετικά processes χρησιμοποιούνται σε επίπεδο συστήματος όταν υπάρχουν isolated application pools, και αυτό είναι επιλογή του administrator. Αν μιλάς για πιό low-level πράγματα, ίσως να έχει μεν ενδιαφέρον, αλλά από ακαδημαϊκής απόψεως και όχι από απόψεως επιδόσεων.
Προς Θεού: ΕΙΜΑΙ microsoft developer, αλλά ούτε ευλογώ τα γένια μου ούτε υποστηρίζω άκριτα μια τεχνολογία/εταιρία. Απλά όταν βλέπω κάτι που δεν καταλαβαίνω προσπαθώ να το κατανοήσω και να το εξηγήσω και / ή να ζητήσω περισσότερες λεπτομέρειες από τον αρχικό γράφοντα.
Σημείωση: Το μήνυμα αυτό γράφτηκε 16 χρόνια πριν. Ο συντάκτης του πιθανόν να έχει αλλάξει απόψεις έκτοτε.