Django, Rails Routing ... Point?

Question

Sono uno studente di sviluppo web (e college), quindi mi scuso se questo sembra ingenuo e offensivo, certamente non intendo in questo modo. La mia esperienza è stata con PHP e con un piccolo progetto all'orizzonte (un calendario a turni glorificato) speravo di imparare uno dei quadri di livello superiore per alleviare il carico del codice. Finora ho guardato CakePHP Symfony Django e Rails.

Con PHP, gli URL sono stati mappati in modo molto semplice ai file e "ha appena funzionato". È stato rapido per il server e intuitivo. Ma con tutti questi quadri, c'è questa inclinazione a "piuttosto". gli URL rendendoli associati a funzioni diverse e instradando i parametri a variabili diverse in file diversi.

" The Rails Way " il libro che sto leggendo ammette che questo è un cane lento ed è la causa della maggior parte dei dolori prestazionali in progetti di grandi dimensioni. La mia domanda è " perché in primo luogo? & Quot ;? C'è un punto specifico nel paradigma url-maps-to-a-file (o mod_rewrite in un singolo file) che richiede regex e schemi di routing complicati? Mi sto perdendo qualcosa non usandoli?

Grazie in anticipo!

Answer 1

• Gli URL dovrebbero essere facili da ricordare e dire. E l'utente dovrebbe sapere cosa aspettarsi quando vede quell'URL. La mappatura dell'URL direttamente sul file non sempre lo consente.
• Potresti voler utilizzare URL diversi per le stesse informazioni, o almeno simili, visualizzate. Se il tuo server ti obbliga a utilizzare 1 url < - > 1 mappatura dei file, è necessario creare file aggiuntivi con tutta la loro funzione di reindirizzare ad altri file. Oppure usi cose come mod_rewrite che non è più facile dei mapping degli URL di Rails.
• In una delle mie applicazioni utilizzo un URL che assomiglia a http://www.example.com/username/ alcune cose aggiuntive / . Questo può essere fatto anche con mod_rewrite , ma almeno per me è più facile configurare gli URL nel progetto django che in ogni istanza di apache in cui eseguo l'applicazione.

solo i miei 2 centesimi ...

Answer 2

La maggior parte è già stata coperta, ma nessuno ha ancora menzionato il SEO. Google attribuisce molta importanza all'URL stesso, se l'URL è widgets.com/browse.php?17, non è molto SEO friendly. Se il tuo URL è widgets.com/products/buttons/, ciò avrà un impatto positivo sul posizionamento della tua pagina per i pulsanti

Answer 3

La memorizzazione del codice dell'applicazione nella struttura dei documenti del server Web è un problema di sicurezza.

• una configurazione errata potrebbe rivelare accidentalmente il codice sorgente ai visitatori
• i file iniettati attraverso una vulnerabilità di sicurezza sono immediatamente eseguibili da richieste HTTP
• i file di backup (creati ad esempio da editor di testo) possono rivelare codice o essere eseguibili in caso di configurazione errata
• i vecchi file che l'amministratore non è riuscito a eliminare possono rivelare funzionalità indesiderate
• le richieste ai file della libreria devono essere esplicitamente negate
• Gli URL rivelano i dettagli dell'implementazione (quale lingua / framework è stato usato)

Nota che tutto quanto sopra non è un problema purché altre cose non vadano male (e alcuni di questi errori sarebbero gravi anche da soli). Ma qualcosa va sempre storto e le linee extra di difesa sono buone da avere.

Answer 4

Anche gli URL di Django sono molto personalizzabili. Con framework PHP come Code Igniter (non sono sicuro di Rails) sei forzato nella struttura / class / method / extra / URL. Sebbene ciò possa essere utile per piccoli progetti e app, non appena si tenta di ingrandirlo / renderlo più dinamico, si verificano problemi e si deve riscrivere parte del codice del framework per gestirlo.

Answer 5

Inoltre, i router sono come mod_rewrite , ma molto più flessibili. Non hanno limiti di espressione regolari e quindi hanno più opzioni per diversi tipi di percorsi.

Answer 6

Dipende da quanto è grande la tua applicazione. Abbiamo un'app abbastanza grande (oltre 50 modelli) e non ci sta causando problemi. Quando lo farà, allora ci preoccuperemo.