2012-10-12 292 views
6

Recientemente se ha destacado (en mis preguntas anteriores) que la forma en que he diseñado las aplicaciones web no es ideal.Código de diseño y estructura

Considere lo siguiente. Estoy trabajando en un sitio web multiusuario con muchas secciones diferentes, incluidos perfiles, foros y tickets de soporte. La estructura es la siguiente:

Una página principal en la que todas las demás páginas están incluidos o * * required_once lo llamaremos home.php.

En home.php, una de las primeras cosas cargadas es router.php, este se encarga de todos y cada uno $ _GET y $ _POST que el usuario podría producir, y cada forma y el proceso se ordena a través de una variable principal llamada $ data_process. Router.php es esencialmente una sola declaración switch() para $ data_process. Esto analiza todos los datos y da un resultado.

El siguiente incluido es header.php, que no solo procesará las variables necesarias para la página que se cargará, sino que también configurará el encabezado y decidirá exactamente qué se va a mostrar allí, p. menú, información del usuario e información sobre la página que está viendo actualmente (es decir, Inicio> Soporte> Ver ticket).

A continuación, la página se carga según la variable $ page. Un simple incluir.

Luego footer.php, luego cierre.

Y así se crea el sitio web dinámico. Me dijeron que esto es una mala práctica por parte de un usuario llamado @HorusKol. Estoy muy satisfecho con este sitio web, ya que es el sitio web más simplificado y fácil de escribir que he usado. Si esto sigue siendo un mal diseño de código? ¿Qué es el diseño de código perfecto?

PD - ¿Alguien puede recomendar cualquier libro fácil de leer que explique PHP, MySQL y la estructura de diseño para mí?

+0

+1 por pregunta honesta. Si home.php es el punto de partida para cualquier solicitud, tiene (al menos un punto de partida) una arquitectura MVC. Felicidades! (y diseño de código perfecto = teoría intacta) – Teson

+0

¡Gracias! Buscaré en la arquitectura MVC. – Chud37

+0

su 'header' está haciendo mucho trabajo ... será difícil mantenerlo en el futuro si desea algunos cambios en futre. – itachi

Respuesta

1
  • Es un mal diseño porque procesa una gran cantidad de datos que quizás no sean necesarios en el resto del proceso. El enrutador solo debe procesar la url, el procesamiento de los datos de la publicación se maneja en otro lugar. Solo incluya lo que necesita, incluido todo lo que hace las cosas más lentas.
  • Una mejor manera es estructurar su aplicación más en diferentes partes. Un enrutador que está procesando la url, un controlador que ejecuta una acción basada en una solicitud enrutada, una vista que procesa todos los html y páginas, un modelo para acceder a los datos. MVC es lo que viene en mente.
  • No existe el diseño de código perfecto.
+0

Pero seguramente la declaración gigante 'switch' solo procesa lo que se necesita para ser procesado? – Chud37

+0

Si procesa su URL como 'http: // mysite.com/controller/action', no necesita un cambio gigante. Obtenga la clase de controlador de la url y deje que el controlador maneje la acción. – JvdBerg

+0

ooh muy interesante .. – Chud37

1

No hay una definición canónica de "buen diseño": lo mejor que puede esperar es que su diseño equilibre las diversas fuerzas en su proyecto de la manera óptima. Las fuerzas en su proyecto pueden ser mantenibilidad, rendimiento, escalabilidad, extensibilidad, requisitos no funcionales clásicos, pero también aspectos como la optimización de motores de búsqueda, cumplimiento de estándares y accesibilidad (cosas que se aplican a proyectos web en particular).

Si todas sus URL tienen el formato "www.misitio.es/home.php?action=getDetails & productID = 123", la simpatía de su motor de búsqueda es bastante baja. Es mucho mejor tener URL semánticas: "www.mysite.com/products/DesktopPc/details.php". Puedes lograr esto a través del astuto truco de .htaccess en tu diseño actual.

Desde el punto de vista de la mantenibilidad, su diseño presenta algunos problemas. Si lo he entendido correctamente, agregar una nueva página al sitio requiere que modifique el código en varios archivos fuente diferentes: router.php (su declaración de cambio gigante), la página misma y probablemente también el header.php. Eso indica que el código está estrechamente coupled. La modificación de la declaración de cambio gigante suena como una fuente probable de errores de entretenimiento, y la combinación del enrutador y el encabezado, la manipulación de las variables, además de la página real en sí parece un poco frágil. Esto está bien si eres la única persona que trabaja en el proyecto, y estarás presente a largo plazo; si ese no es el caso, es mejor usar un marco estándar (MVC es el favorito actual; Zend, Symphony y Cake hacen todo esto bien en PHP) porque puedes apuntar a nuevos desarrolladores sobre la documentación y esperar que obtengan hasta la velocidad.

Uno de los mayores enemigos de la mantenibilidad es la complejidad: el código complejo es más difícil de trabajar y alberga más errores. Hay un formal metric para la complejidad, y estoy bastante seguro de que tu declaración de cambio puntúa muy bien en esa métrica, en sí misma no necesariamente un gran problema, pero definitivamente algo a tener en cuenta. Muchos frameworks MVC evitan esto al tener el enrutamiento definido como datos en lugar de código (es decir, tienen las rutas en un archivo de configuración), y/o usando convención sobre configuración (es decir, si la solicitud es para la página "productDetails", incluya el archivo "/inc/productDetails.inc").

La extensibilidad podría ser otra preocupación: imagine tener que exponer el contenido de su sitio como JSON o XML, así como HTML; en su diseño actual, eso requeriría una gran cantidad de cambios, porque cada ítem en el pipeline de procesamiento de su página se preocupa y necesita saber. El home.php necesita saber que no se debe enviar HTML, el encabezado y el pie de página deben saber que el enrutador necesita comprender cómo manejar el tipo de datos adicional, lo que casi seguramente hará que la declaración del conmutador sea aún más grande. Esto de nuevo puede no ser un gran problema.

Tanto la capacidad de extensión como la de mantenimiento se ayudan al poder probar el código de la unidad. Test Driven Development lo convierte en una rutina completa por derecho propio; Supongo que probar tu aplicación es difícil, pero eso es solo una suposición; depende más de cómo haya tenido en cuenta los grumos de código individuales de lo que ha descrito anteriormente. Sin embargo, otro beneficio de MVC es que facilita la escritura de pruebas de unidad para partes clave de su sistema.

Por lo tanto, si las fuerzas en su proyecto no incluyen un énfasis en facilidad de mantenimiento o extensibilidad, y puede manejar el aspecto de SEO, no creo que su diseño sea necesariamente "malo"; incluso si te importan esas cosas, hay otras cosas que puedes hacer para acomodar esas fuerzas: escribe documentación, contrata muchos codificadores baratos.

La mejor manera de ponerse al día con estos temas de diseño no son los libros en PHP o MySQL; Recomendaría "Refactoring" y "Patrones de la arquitectura de aplicaciones empresariales" de Martin Fowler, "Design Patterns" de Gamma et al. y Code Complete por McConnell (aunque ya está un poco desactualizado).

Cuestiones relacionadas