¿Cómo implementar estilo MVC en mi código PHP / SQL / HTML / CSS?

¿Tiene alguna sugerencia sobre cómo separar con éxito HTML / CSS de PHP / SQL?

Felicidades por ver cómo puedes mejorar el código. Esa es la condición previa, debe querer mejorarla y el tema es extenso. Entonces tu voluntad es crucial.

Comienzo ligeramente y luego trato de dar algunos consejos. Como le falta experiencia, busque un punto para empezar, sin duda el último de la list a continuación. Pero primero lo primero:

Para separar algo el uno del otro, necesitas tener un código que separe:

[HTML/CSS/PHP/SQL] [HTML/CSS] <--> [SEPARATOR] <--> [PHP/SQL] 

El separador aquí también es código PHP, pero creo que entiendes la idea.

Como puede ver, solo el Separador habla con HTML / CSS y PHP / SQL .

Entonces, tanto HTML / CSS como PHP / SQL necesitan tener una interfaz con Separador (la línea entre) para que esto funcione.

Normalmente, en un progtwig, se pasan datos que se procesan. Los datos son bastante dynamics y pueden tener una complejidad compuesta, especialmente si pasa los datos a una rutina de salida que debe formatearla adecuadamente.

Hay muchas forms de escribir dicho Separador (o varios de ellos). Puede aplicar capas a su software o proporcionar componentes que hacen cosas en su área o dominio . Por ejemplo, tiene una capa de database o componente de database que se ocupa de la interacción con la database.

O tiene un motor de templates que se encarga de poner sus cadenas y matrices en un HTML legible.

En resumen, esta es la teoría de pasta del layout de software:

• Código de espagueti : todo en uno, el código está muy entrelazado, es preferible con Bolognese o Aglio, Olio e Peperoncino.
• Código de lasaña : en capas, una capa tiene otras dos capas con las que interactúa (a less que esté en la parte inferior o superior), siempre con salsa Béchamel.
• Código Tortelini : componentes pequeños que simplemente hacen su trabajo, tienen carne o verduras picantes adentro.

Al igual que comemos pasta diferente en nuestras vidas, cuando progtwigmos también tenemos que lidiar con todos estos types diferentes de código, y desarrollamos nuestro gusto preferido a lo largo del time. Cuando éramos niños nos alimentamos, pero con el time empezamos a cocinar algo propio y a variar las recetas.

Así que creo que es un buen punto que simplemente no quiera ahora comer MVC Framework X con algo increíble durante las próximas semanas solo porque alguien le dijo que es la manera de comer ahora. Y antes de comer, hay una degustación, ¿verdad? Sin mencionar la comida rápida, ya sabes como estos fideos con salsa en el package, solo agrega agua. Urgh.

No sé qué datos necesita tu salida y cuál es la input. A continuación, se incluyen algunos consejos de refactorización para aplicaciones que generan HTML / CSS e interactúan con una database MySQL. Esta no puede ser una list completa y las descripciones solo pueden resumir algunos pensamientos:

• Mueva CSS de HTML . Use los selectores de manera efectiva en la definición de CSS enlazado y reemplace cualquier atributo de style si aún tiene alguno. Esto hace que tu código CSS sea reutilizable y más modular. Le ayudará a encontrar defectos dentro de su HTML y a separar la Estructura (HTML) de la Presentación (CSS). El HTML efectivo comienza con el uso efectivo de CSS, esos dos son muy potentes juntos y, a menudo, esto ya aligerará las rutinas de salida de tus progtwigs.
• Mueva la lógica comercial fuera de HTML . Tanto HTML como tu código pueden ser una bestia, así que mejor mantenerlos separados. Tienen la tendencia a pelear entre ellos, y como ambos son muy poderosos, la pelea continuará mientras desarrollas tu aplicación, que te distrae del trabajo que necesitas hacer.
  Considere si necesita tener un resultado complejo dentro de su aplicación o si puede pasar matrices con subelementos (una key es una var, una var puede contener una cadena o un número u otra var-array). Normalmente todo eso es necesario para pasar incluso datos complejos en una vista o plantilla . Entonces, HTML solo necesita hacer eco de algunos miembros de la matriz o de foreach sobre subarrays. Esta es una técnica muy simple para crear una plantilla. Puede usar PHP para ello, por lo que en realidad es realmente flexible (simplemente dibuje el borde que pertenece a su capa de vista y que es parte de la aplicación, por ejemplo, proporciona valores para la vista).
• Mueva SQL de su código . Mueva el código de interacción de la database. Cree usted mismo uno o varios objects que tengan methods que devuelvan los datos de la manera que necesite (consum) en su código de procesamiento real, como $component->getThatData() que luego devuelve los datos en una forma normalizada. Haga que esos componentes luego usen un componente de database dedicado para hablar con la database. En el código de su aplicación (lógica comercial), solo use el componente de la database y preferiblemente los objects que cree para get los datos, de modo que ya no tenga ninguna línea de SQL dentro de su código principal.
• Divide y conquista el código de tu aplicación: divide tu código en Scripts de transacción . A menudo son fáciles de crear a partir del código de spaghetti existente y probablemente se convertirán en dicho separador que está buscando en términos medios. Luego tendrán la function de procesar los datos y transmitirlos (a la salida / vista).
• Use un lenguaje claro : si tiene datos de cadena formateados complejos que no están normalizados, escriba usted mismo las classs de analizador que hacen el trabajo por usted y que pueden reutilizarse fácilmente (si ese es el caso en su aplicación). Como debe esperar para minimizar el uso de SQL simple en su código, también debe esperar mover expresiones regulares complejas también. Encapsular lo que varía es un punto key. Lo mismo se aplica a las rutinas largas para manejar solo algunos datos (p. Ej. Ordenarlos, orderarlos y orderarlos en otro formatting), moverlos a componentes propios y pensar cómo hacerlos accesibles y reutilizables.
• Haga que su código funcione : descubra la lógica de cómo invocar la funcionalidad en su progtwig. Puede intentar separar la funcionalidad de la forma en que se invoca. Por ejemplo, alguna rutina que invoca cualquiera de los Scripts de Transacción . Esto puede no ser necesario si solicita files PHP directamente a través del browser, ya que esos son entonces sus scripts de transacción y el server web se ocupa de resolver el command enviar a través de URL a su aplicación al script de transacción. Pero debe ajustar la lógica necesaria para procesar el command entrante y sus parameters en componentes reutilizables (por ejemplo, una class Request que contenga un código estándar para get la URL o las variables de una request HTTP).
• Cree un punto de input común incluyendo el mismo file en la parte superior de todos los files que se llaman a través del browser. A continuación, puede poner en él un código común (como configurar el object de estado de session de la aplicación e inicializar el componente de la database), consulte también Controlador de aplicación
• Elimine la duplicación buscando literalmente el código duplicado. Envuélvalo en una function o class. Cree una carpeta de biblioteca para su propia aplicación en la que inserta sus inclusiones. Si sigue un patrón común con Classnames y Namespacing, puede usar fácilmente un autocargador para mantener la inclusión fácil. Haga que su biblioteca se aparte del código de un tercero. Coloque todos los códigos de terceros en una carpeta de biblioteca propia con un subdirectory para cada componente de terceros.
• Use componentes ligeros y existentes. El peso ligero es importante porque ya tienes tu propio código, no quieres girarlo y presionarlo todo a la vez en un marco. La existencia es importante porque no quiere redevise la rueda. Tendrás trabajo suficiente para tu propia refacturación de tu código. Después de que se sienta mejor con su aplicación y aún tenga poder y voluntad, siempre puede escribir todo lo nuevo. Pero si estás solo o en un equipo pequeño, Existing es bastante poderoso. Las bibliotecas simples son, por ejemplo:
  • Templating motor: bigote
  • Capa de database: NotORM
• Cree el estado de la aplicación , por ejemplo, como un object que puede utilizar en caso de que algunos componentes necesiten conocer el estado de la aplicación o entre sí sin interacción directa. Por defecto en PHP, si no tiene uno, las variables estáticas globales y globales se utilizan para crear el estado. Sin embargo, estas variables pueden hacer que su vida sea más difícil a medida que crece el código. Cuando crea un object de estado de aplicación, queda claro qué componentes lo utilizan, el acceso a él puede controlarse (por ejemplo, llamar a un método en lugar de leer una variable, lo que puede ayudar a depurar) y los componentes también pueden descubrir si es momento adecuado en el flujo de la aplicación para entrar en acción. También es una buena herramienta para refactorizar tu código a lo largo del time.
• Preserve una aplicación de trabajo , mantenga su código en un estado para ejecutar. Idealmente, esto sería respaldado por testings automáticas. Considere que necesita reescribir mucho. Por ejemplo, si comienza a integrar un componente de database, hágalo. Mueva todo su código existente en un solo paso. Entonces, ¿quién te dice que aún se ejecuta? Usa git para deshacer mejor y probar cosas. Eso es más importante que elegir la biblioteca correcta. Preservar una aplicación que funcione también es siempre el punto key porque es por eso que la cambias, ¿verdad?

¿Por qué no usar un motor de templates? TWIG es muy fácil de usar y excelente para este tipo de cosas. A menudo se usa con el marco Symfony, pero puede usarse fácilmente por sí mismo.