Django, Rails Routing… ¿Punto?

Question

Soy un estudiante de desarrollo web (y de la universidad), así que mis disculpas, si esto resulta sonar ingenuo y ofensivo, ciertamente no lo digo de esa manera. Mi experiencia ha sido con PHP y con un pequeño proyecto en el horizonte (un calendario de turnos glorificado) esperaba aprender uno de los marcos de nivel superior para aliviar la carga del código. Hasta ahora, he mirado CakePHP Symfony Django and Rails.

Con PHP, las URL se asignaron de manera muy simple a los archivos, y "funcionó". Fue rápido para el servidor, e intuitivo. Pero con todos estos marcos, existe esta inclinación a " bastante arriba " las URL al hacer que se asignen a diferentes funciones y enrutar los parámetros a diferentes variables en diferentes archivos.

" The Rails Way " El libro que estoy leyendo admite que esto es lento y es la causa de la mayoría de los problemas de rendimiento en proyectos grandes. Mi pregunta es " ¿por qué tenerla en primer lugar? & Quot ;? ¿Hay un punto específico en el paradigma url-maps-to-a-file (o mod_rewrite en un solo archivo) que requiere expresiones regulares y esquemas de enrutamiento complicados? ¿Estoy perdiendo algo al no usarlos?

Gracias de antemano!

Answer 1

• Las URL deben ser fáciles de recordar y decir. Y el usuario debe saber qué esperar cuando vea esa URL. La asignación de URL directamente al archivo no siempre permite eso.
• Es posible que desee utilizar diferentes URL para la misma información, o al menos similar, que se muestra. Si su servidor le obliga a utilizar 1 url < - > 1 asignación de archivos, debe crear archivos adicionales con todas sus funciones para redirigir a otro archivo. O usas cosas como mod_rewrite que no es más fácil que las asignaciones de URL de Rails.
• En una de mis aplicaciones, uso una URL que se parece a http://www.example.com/username/ algunas cosas adicionales / . Esto también se puede hacer con mod_rewrite , pero al menos para mí es más fácil configurar las URL en el proyecto django que en cada instancia de Apache en la que ejecuto la aplicación.

solo mis 2 centavos ...

Answer 2

La mayoría ya se ha cubierto, pero nadie ha mencionado el SEO todavía. Google pone mucho peso en la URL, si esa URL es widgets.com/browse.php?17, eso no es muy amigable para SEO. Si su URL es widgets.com/products/buttons/, tendrá un impacto positivo en el rango de su página para los botones

Answer 3

El almacenamiento del código de la aplicación en el árbol de documentos del servidor web es un problema de seguridad.

• una configuración errónea podría revelar accidentalmente el código fuente a los visitantes
• los archivos inyectados a través de una vulnerabilidad de seguridad son ejecutables inmediatamente por las solicitudes HTTP
• los archivos de copia de seguridad (creados, por ejemplo, por editores de texto) pueden revelar un código o ser ejecutables en caso de una mala configuración
• los archivos antiguos que el administrador no ha podido eliminar pueden revelar una funcionalidad involuntaria
• las solicitudes a los archivos de la biblioteca deben ser denegadas explícitamente
• Las URL revelan detalles de la implementación (en qué idioma / framework se usó)

Tenga en cuenta que todo lo anterior no es un problema siempre que otras cosas no salgan mal (y algunos de estos errores podrían ser graves, incluso solos). Pero algo siempre sale mal, y es bueno tener líneas de defensa adicionales.

Answer 4

Las URL de Django también son muy personalizables. Con marcos de trabajo de PHP como Code Igniter (no estoy seguro de Rails), debe ingresar a la estructura / class / method / extra / URL. Si bien esto puede ser bueno para pequeños proyectos y aplicaciones, tan pronto como lo intente y lo haga más grande / dinámico, tendrá problemas y tendrá que volver a escribir parte del código del marco para manejarlo.

Answer 5

Además, los enrutadores son como mod_rewrite , pero mucho más flexibles. No están vinculados a expresiones regulares y, por lo tanto, tienen más opciones para diferentes tipos de rutas.

Answer 6

Depende de qué tan grande es tu aplicación. Tenemos una aplicación bastante grande (más de 50 modelos) y no nos está causando ningún problema. Cuando lo haga, nos preocuparemos por eso.