Ancora su ASP.Net vs Php

[OxiDe]

Innanzitutto un saluto a tutti

Si potrebbe intitolare "Yet Another Topic about ASP.Net vs Php" visto che ce ne sono una marea, lo so :gren:

Cmq personalmente ho una domanda specifica, più che riproporre le solite domande a cui, naturalmente, sarete stanchi di rispondere.
Premetto che ho una ottima conoscenza di ASP (e per ottima intendo ottima ) e diversi linguaggi, ma mi sto avvicinando soltanto ora a .Net in quanto ho troppe applicazioni web da convertire e naturalmente questo richiederà i suoi tempi.
Avendo letto, nei soliti thread della serie, appunto, "Asp.Net vs Php", ho letto fra i commenti degli intervenuti qualcuno in cui si afferma che con Php si possono fare praticamente le stesse cose che con Asp.Net. Php l'ho usato soltanto un po' due anni fa, credo, dopo di che avendo continuamente a che fare con sistemi Ms per Sql Server ecc. si è sempre preferito per una serie di cose procedere in Asp (anche se naturalmente era perfettamente possibile anche l'alternativa). Quindi non so come si sia evoluto nel frattempo; il dubbio più forte che ho a riguardo del confronto fra .Net e appunto Php riguarda i controlli lato server: in .Net è per me esattamente come programmare in un ambiente visuale non web, come quando si sviluppa una normale applicazione non web... e poi i controlli server sono una figata, qualcosa che rende le pagine più dinamiche che mai, grazie alla possibilità di aggiornare i dati di ogni singolo controllo senza ricaricare la pagina, in tempo reale, in risposta all'interazione utente-applicazione web. Ecco, la domanda è: Php, oggi, offre questa possibilità? Oppure, in questo, non è superiore al normale Asp, col solito vecchio sistema di scambio dati fra client e server?

Un grazie in anticipo a chi vorrà delucidarmi su questo che è rimasto per me l'unico dubbio in merito a questo tema. Per tutto il resto, non ho dubbi: passare a .Net è come tornare a sviluppare le normali applicazioni Windows che ho sempre fatto prima di sviluppare applicazioni intranet basate su Asp, con una marea di vantaggi.

[Trinità]

qualcosa che rende le pagine più dinamiche che mai, grazie alla possibilità di aggiornare i dati di ogni singolo controllo senza ricaricare la pagina, in tempo reale, in risposta all'interazione utente-applicazione web

no, mica fa miracoli asp.net ! si tratta sempre di un linguaggio lato server, se vuoi nuove informazioni devi ricaricare la pagina ! e non ci sono santi.
L'unica cosa è che ti fà lui i controlli javascript che senza inviare la pagina ti dice immediatamente alcune cose.

quando inventeranno la tecnologia che dici tu non andremo più con http credo...

[OxiDe]

Forse mi sono espresso male

Quello che intendevo, cerco di chiarirlo con un esempio:

Ho una pagina ClassicAsp, in cui ho un form con una select contenente dei valori. Nella pagina è presente anche una tabella generata dinamicamente da un recordset, con dei dati filtrati in base al valore selezionato nella select di cui sopra. Utilizzando le normali Asp, potrei procedere in questi modi (escludendo il remote scripting):
1 - metto select e codice che aggiorna la tabella generata dinamicamente nella stessa pagina: in questo caso, per vedere aggiornata la tabella con l'invio del form (ad es attivato all'onChange della select), viene ricaricata completamente l'intera pagina, e c'é stato un passaggio di parametri, che sia via GET o POST, comunque "visibile" e su cui si può "intervenire" (ad es. giocando coi form di login, qualora chi li ha sviluppati non abbia aggiunto il controllo della provenienza dei dati del form).
2 - metto nella pagina un iframe (o frame, insomma il concetto è quello), in un cui una seconda pagina contiene il codice che genera la tabella coi dati filtrati in base alla selezione della select. In questo caso non vedo ricaricarsi l'intera pagina quando cambio la voce selezionata, ma soltanto l'iframe. Ma il discorso del passaggio di parametri nel modo tradizionale non è cambiato.

In .net, ho una sola pagina, contenente una listbox e un datagrid, entrambi controlli server. Gestisco gli eventi in modo che cambiando la voce selezionata nella listbox, venga eseguito il codice che rigenera il datagrid coi dati filtrati in base alla nuova selezione.
In questo caso, io non ho passato dei parametri da una pagina all'altra, né con GET né con POST. Quindi penso che sia molto più sicuro così, oltre che 'comodo' in termini di realizzazione.
Se come tu dici comunque la pagina viene ricaricata anche se non me ne accorgo, comunque non c'é un passaggio di parametri come con asp sul quale un malintenzionato possa intervenire. Giusto, o mi sbaglio?

Nel caso sia come ho detto, la domanda è: con php questo è possibile, oppure c'é sempre il passaggio di parametri come con asp?

Altrimenti, sarei lieto di ricevere qualche chiarimento in merito a come .net elabora le interazioni fra diversi controlli di una stessa pagina.

[DeBe99]

Originariamente inviato da Trinità
no, mica fa miracoli asp.net ! si tratta sempre di un linguaggio lato server, se vuoi nuove informazioni devi ricaricare la pagina ! e non ci sono santi.
L'unica cosa è che ti fà lui i controlli javascript che senza inviare la pagina ti dice immediatamente alcune cose.

quando inventeranno la tecnologia che dici tu non andremo più con http credo...

Non è completamente vero, asp.net gestiscie una VievState lato server con tutti i dati che compongono la pagina. Se la pagina torna al server per una richiesta, i dati sono già disponibili e non occorre ricaricarli dal database. Dal punto di vista del client la pagina viene ricaricata, ma dal lato server no, e questo contibuisce a diminuire di molto gli accessi al database e i tempi di risposta.
Non conosco PHP, e non so se anche con lui e possibile gestire cosi i dati si postback e la vievstate.

[DeBe99]

Originariamente inviato da OxiDe
...

In realta la comunicazione client server rispetto ad ASP non è cambiata, i dato vengono comunque inviati con i form, tenendo però nascosto il passaggio. I dati postati indietro dal form indicheranno (oltre ai dati veri e propri) gli eventi da generare lato server. I Browser funzionano comunque ancora con HTML/Javascript

[Trinità]

In questo caso, io non ho passato dei parametri da una pagina all'altra, né con GET né con POST.

non è vero li hai passati via post (il viewsate lo mandi, prova a non attivarlo e ti accorgerai che sei nel vecchio mondo asp)

comunque non c'é un passaggio di parametri come con asp sul quale un malintenzionato possa intervenire

può intervenire più difficilmente, MOOOOLTO PIU' difficilmente (il campo viewsate lo puoi criptare vedi viewsatet MAC)

Se come tu dici comunque la pagina viene ricaricata

SU questo non ci sono santi, viceversa hai già portato tutto "di quà" (lato client intendo) e con qualche giochetto javascript o comunque lato client lo ripeschi

Se la pagina torna al server per una richiesta, i dati sono già disponibili e non occorre ricaricarli dal database

dipende che dati: magari all'inizio avevi popolato la select (dropdownlist) e quindi non te ne frega niente (anzi meglio) non ripopolarla al prossimo page_load, ma la tabella sotto che deve venire filtrata quella te la devi ricaricare, nel senso che devi chiedere i dati al tuo db.

In ogni caso certamente sì ci sono dei vantaggi causa il minore stress del DB

[OxiDe]

Quindi sicurezza maggiore + maggiori prestazioni, vero?

[Trinità]

Quindi sicurezza maggiore + maggiori prestazioni, vero?

Totalmente d'accordo

[giorgiotave]

daccordo anche io