Pregunta

No estoy seguro de cómo debería expresar esto, pero lo intentaré.
Recientemente comencé a codificar mi cartera en PHP orientado a objetos y me pregunto si está de acuerdo con las mejores prácticas usar una sola página donde el contenido cambia dependiendo de los datos SQL y la variable $_GET.

Si es así/no, ¿por qué?

Editar:Echa un vistazo a mi próxima publicación, más detalles en profundidad.

¿Fue útil?

Solución

¿Está preguntando acerca del uso del patrón del controlador frontal, donde un solo archivo atiende todas sus solicitudes?A menudo, esto se hace con index.php y mod_rewrite obteniendo todas las solicitudes y el resto de la URL se le proporciona como parámetro en la cadena de consulta.

http://www.onlamp.com/pub/a/php/2004/07/08/front_controller.html

Yo tendería a recomendar el uso de este patrón para aplicaciones, porque le brinda un lugar único para manejar cosas como la autenticación y, a menudo, necesitará integrar cosas en un nivel más estricto en el que las nuevas características sean clases que estén registradas con el controlador. a través de algún mecanismo tiene mucho sentido.

Las preocupaciones sobre las URL que otros han mencionado no son realmente precisas, porque no existe una relación real entre la estructura de la URL y la estructura del archivo, a menos que esté utilizando técnicas antiguas de creación de sitios web.Una buena parte de la funcionalidad de Apache se basa en el concepto de que la estructura de archivos/directorios y la estructura de URL son conceptos distintos (módulo de alias, módulo de reescritura, negociación de contenido, etc.)

Otros consejos

  • No escalable
  • Código difícil de administrar
  • El analizador tiene que analizar todo.
  • Ejemplo perfecto de Code Smell
  • Un error bloquea todo tu sitio

Si te refieres a una única página de destino (p. ej.index.php) que luego usa variables de sesión, etc.para determinar qué código se debe incluir, entonces sí, esta es una técnica de uso frecuente.

Editar:y con lo anterior me refiero a lo que Daniel Papasian explica detalladamente en su excelente post

Si te refieres a colocar todo tu HTML, SQL y PHP en un solo archivo, entonces no, por las razones señaladas por GateKiller.

El archivo de la página actual debe contener sólo lo que es diferente de esa página de una "página" estándar en su sitio (por ejemplo, el título de la página, la página de índice puede tener código para obtener las últimas noticias, etc.).Todo lo que se usa (o puede) usarse en más de un lugar debe moverse a archivos php externos e incluirse.Ejemplos son:

  • Información de la base de datos (contraseña, nombre de usuario, etc.)
  • Encabezado/pie de página
  • código de inicio de sesión

Esto hace que el código sea mucho más fácil de administrar.Por ejemplo, si cambia la contraseña de la base de datos, solo es necesario actualizar un archivo, o si decide agregar un banner al encabezado, nuevamente es solo una página, no todas las páginas que deben cambiarse.

También hace que agregar nuevas funciones sea mucho menos complicado, por ejemplo, una nueva página puede ser simplemente:

<?php
require ('config.php')
require ('start.php')
require ('header.php')
//custom page stuff
require ('footer.php')
?>

o agregar inicio de sesión automático a través de cookies, es un simple cambio en la función Login() (crear una cookie) y start.php (verificar la cookie + llamar a Login()).

También puedes transferir fácilmente estos archivos a otros proyectos en el futuro.

Todo lo que mencionó Gatekiller + tampoco se puede utilizar el enlace tardío.

  • Código difícil de administrar

Si está utilizando el control de versiones, será MUCHO más difícil revertir cualquier cambio que pueda haber ocurrido en una sola "página" de su sitio.Ya que tendrías que volver a fusionarte para cualquier cosa que pudiera haber venido después.

No es tan amigable para los motores de búsqueda a menos que uses mod rewrite

Tiendo a no estar de acuerdo con la mayoría: si su sitio está administrado por un CMS personalizado o algo similar, no hay razón para no usar una página.

Hice algo similar con un CMS que escribí hace un tiempo.Todos los clientes tenían una única página default.asp que consultaba en la base de datos el tema, el contenido, los archivos adjuntos y los permisos de los miembros.Para realizar un cambio, simplemente lo hice una vez y lo copié a mis otros clientes si el cambio lo requería.

Por supuesto, esto no funcionaría en la mayoría de los escenarios.Si tiene un sitio web que hace muchas cosas DIFERENTES (mi cms simplemente repitió ciertas funciones mientras cargaba la página), entonces varias páginas son realmente el único camino a seguir.

Para aquellos de ustedes que estén interesados, existe un marco que utiliza este modelo exacto.Originalmente para ColdFusion.Todavía existe una comunidad para esta metodología, la versión 5.5 se lanzó hace aproximadamente un año (diciembre de 2007).

Sitio del marco FuseBox

entrada de wikipedia

Este volcado de pantalla y la siguiente explicación podrían dar una mejor idea de cómo se ve mi código en este momento.

File-structure

Utilizo el mismo modelo que menciona 'Internet Friend', Daniel Papasian y algunos otros;Controlador frontal.

Mi página de índice se ve así.

require_once 'config.php';
require_once 'class_lib/template.php';

$template = new template($config);
$template->dataQuery();
$template->pageCheck();
$template->titleAssembly();
$template->cssAssembly();
$template->metaAssembly();
$template->menuAssembly();
$template->content();
echo $template->publish();

La construcción de clase abre el archivo de plantilla principal y lo carga en una variable que cada método puede manipular reemplazando etiquetas con código generado.Las URL feas no son realmente un problema ya que usaré mod_rewrite para limpiarlas.
Sin embargo, Papasian tiene razón: este método sería más adecuado para aplicaciones basadas en web y similares.

En primer lugar, me disculpo por no ser muy específico con mi pregunta.
Además, muchas gracias a todos los que escribieron unas líneas para ayudar.

A menudo uso un archivo php sin la extensión .php (es decir, sitio) y agrego

<Files site>
ForceType application/x-httpd-php 
</Files>

al .htaccess que hace que Apache interprete el archivo como un archivo php.

Puede analizar vars al archivo dentro de la URL: http://www.tudominio.com/site/var1/var2/var3

Usar

$var_array = explode("/",$_SERVER['REQUEST_URI']); 
$var1 = $var_array[1];
$var2 = $var_array[2];
$var3 = $var_array[3];

para obtener las vars.De esta manera, puede utilizar un solo archivo con URL amigables para la búsqueda sin modrewrite.

re:URL y estructura de archivos

Convertí un sitio donde todo el contenido estaba en una base de datos y accedí con el modelo index?p=434.No había ningún beneficio al usar la base de datos y el sitio resultaba confuso para las personas que tenían que agregar contenido, ya que tenían que editar el contenido con el navegador y las páginas eran solo números.

Saqué todo el contenido y lo puse en archivos separados.Cada uno tenía un nombre práctico y estaba organizado en carpetas.Cada archivo se parecía a esto:

require('sitelib');
do_header('about', 'About Us');
// content here
do_footer();

Al cliente le encantó.Pudieron usar cualquier editor HTML para ingresar, encontrar el archivo correcto y realizar el cambio.Y pudieron hacer nuevas páginas.Todo para decir:A veces, es útil que la URL y las estructuras del archivo coincidan.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top