Django, Rails Routing ... Point?

Question

Eu sou um estudante de desenvolvimento web (e superior), então as minhas desculpas se isso vem fora de soar ingênuo e ofensivo, eu certamente não dizer isso. Minha experiência tem sido com PHP e com um projeto pequeno no horizonte (um calendário de mudança glorificado) eu esperava para aprender uma das estruturas mais altas de nível de aliviar a carga de código. Até agora, eu olhei para CakePHP Symfony Django e Rails.

Com o PHP, as URLs mapeados de forma muito simples para os arquivos, e "simplesmente funcionou". Foi rápido para o servidor, e intuitiva. Mas com todas estas estruturas, há esta inclinação para "embelezar" os URLs, tornando-os mapear para diferentes funções e encaminhar os parâmetros para diferentes variáveis ??em diferentes arquivos.

"The Rails Way" livro que estou lendo admite que este é cão lento e é a causa da maioria das dores de desempenho em projetos bastante largo. A minha pergunta é "por tê-lo em primeiro lugar?"? Existe um ponto específico no paradigma url-mapas-to-a-arquivo (ou mod_rewrite em um único arquivo) que necessita de expressões regulares e esquemas de roteamento complicado? Am I perdendo algo por não usá-los?

Agradecemos antecipadamente!

Answer 1

• URLs deve ser fácil de lembrar e dizer. E o usuário deve saber o que esperar quando ela ver que URL. Mapeamento URL diretamente para o arquivo nem sempre permite isso.
• Você pode querer usar URLs diffrent para o mesmo, ou pelo menos semelhante, a informação exibida. Se o seu servidor força-lo a usar um url <-> 1 mapeamento de arquivo, você precisa criar arquivos adicionais com toda a sua função é redirecionar para outro arquivo. Ou você usar o material como mod_rewrite que não é fácil, então mapeamentos de URL do Rails.
• Em uma das minhas aplicações eu uso URL que se parece com http://www.example.com/ nome de usuário / algum material adicional /. Isso também pode ser feito com mod_rewrite, mas pelo menos para mim, é mais fácil urls configurar no Django projeto, em seguida, em todos os casos apache eu executar o aplicativo no.

apenas meus 2 centavos ...

Answer 2

A maior parte dele já foi coberto, mas ninguém mencionou SEO ainda. Google coloca muito peso sobre o próprio URL, se isso url é widgets.com/browse.php?17, que não é muito SEO amigável. Se o seu URL é widgets.com/products/buttons/ que terá um impacto positivo sobre o seu page rank para os botões

Answer 3

código de aplicativo de armazenamento na árvore de documentos do servidor web é uma preocupação de segurança.

• uma configuração incorreta pode acidentalmente revelar o código-fonte para os visitantes
• arquivos injetados através de uma vulnerabilidade de segurança são imediatamente executável por solicitações HTTP
• arquivos de backup (criado por exemplo, editores de texto) pode revelar código ou ser executável em caso de erro de configuração
• arquivos antigos que o administrador não foi capaz de eliminar pode revelar funcionalidade não intencional
• solicitações para arquivos de biblioteca devem ser explicitamente negado
• URLs revelar detalhes de implementação (que / framework foi utilizada a linguagem)

Note-se que todos os itens acima não são um problema, desde que outras coisas não correrem mal (e alguns desses erros seria grave mesmo sozinho). Mas alguma coisa sempre dá errado, e as linhas extras de defesa são bons de ter.

Answer 4

URLs Django também são muito personalizável. Com frameworks PHP como Code Igniter (não tenho certeza sobre Rails) seu forçados para a classe / método / Extra / estrutura / URL. Embora isso possa ser bom para pequenos projetos e aplicativos, assim que tentar e torná-lo maior / mais dinâmico você tiver problemas e ter que reescrever parte do código estrutura para lidar com isso.

Answer 5

Além disso, os roteadores são como mod_rewrite, mas muito mais flexível. Eles não são regulares, e, assim, obrigado-expressão, tem mais opções para diferentes tipos de rotas.

Answer 6

Depende de quão grande é a sua aplicação é. Nós temos um aplicativo bastante grande (50+ modelos) e não está nos causando problemas. Quando isso acontecer, vamos preocupar com isso depois.