stript - quitar tags php

PHP: un marco personal

Question

Voy a escribir un marco para mis proyectos web en PHP. Por favor, no me digas si considero usar algún framework existente (Cake, CodeIgniter, Symfony, etc.). Ya los he visto y he decidido escribir uno para mí.

El marco en sí consistirá principalmente en un sistema de módulos, un manejador de base de datos y un analizador de plantillas. (Muchas otras cosas también, por supuesto)

Con el sistema de módulos quiero decir que cada módulo tiene exactamente un archivo PHP y una o más plantillas asociadas. Un módulo de ejemplo sería modules/login.php que usa templates/login.tpl para su diseño.

En estos días, todos (?) Hablan sobre el concepto MVC (Controlador de vista de modelo) y la mayoría de los marcos existentes también lo usan.

Entonces mis preguntas son las siguientes:

• ¿MVC es realmente efectivo para un marco personal?
• ¿Sería una mala idea usar un sistema de módulos?
• ¿Alguna vez escribiste un marco para ti? ¿Cuáles son tus experiencias?

Answer 1

1. MVC no funciona
2. no quiere estar limitado en la estructura de sus "módulos"; también, mantenga las plantillas cerca del código (el directorio de templates es una mala idea)
3. no

re 1 .: ver Holub de Holbot en Patrones. brevemente: MVC básicamente requiere que abandones los principios orientados a objetos.

Tell Do not Ask es un nombre pegadizo para un truco mental que te ayuda a mantener unidos los datos y el código que actúa sobre él . Las vistas hacen que el Modelo se degrade en un montón de getters y setters, con pocas o ninguna operación significativa definida en ellos. El código que, naturalmente, pertenece al Modelo se distribuye en la práctica entre los Controladores y las Vistas (!), Lo que produce la Acción distante insalubre y el acoplamiento estrecho.

Los objetos modelo deben mostrarse ellos mismos, posiblemente usando alguna forma de Inyección de Dependencia:

interface Display
{
function display($t, array $args);
}
class SomePartOfModel
...
{
function output(Display $d)
{
$d->display(''specific.tpl'', array(
''foo'' => $this->whatever,
...
));
}
}

OTOH, en la práctica, encuentro que la mayoría de las aplicaciones web requieren un patrón arquitectónico diferente, donde el Modelo se reemplaza con Servicios . Una base de datos activa, un esquema normalizado y vistas específicas de la aplicación son de gran utilidad: conserva los datos y el código que actúa sobre ellos juntos , y la naturaleza declarativa lo hace mucho más corto que lo que podría hacer en PHP.

Ok, entonces SQL es un lenguaje terriblemente detallado. ¿Qué le impide generarlo desde un DSL conciso? Eso sí, no necesariamente sugiero usar un ORM. De hecho, todo lo contrario. Sin Modelo , de todos modos, hay poco uso para un ORM. Es posible que desee utilizar algo para generar consultas, aunque éstas deberían ser muy simples, tal vez hasta el punto de obviar dicha herramienta ...

Primero, mantenga la interfaz que su base de datos expone a la aplicación lo más cómoda posible para la aplicación. Por ejemplo, oculte consultas complejas detrás de las vistas. Exponer las interfaces específicas de la actualización cuando sea necesario.

La mayoría de las aplicaciones web no son solo los propietarios de sus respectivas bases de datos subyacentes, sino que son sus únicos consumidores. A pesar de este hecho, la mayoría de las aplicaciones web acceden a sus datos a través de interfaces incómodas: un esquema normalizado, esqueleto o un esquema desnormalizado que facilitó una operación a costa de una gran incomodidad en otros lugares (varias columnas de estilo csv, etc.) . Eso es un poco triste e innecesariamente.

re 2 .: sin duda es bueno tener una estructura unificada. lo que no quiere hacer es encerrarse en una situación en la que un módulo no puede usar más de un archivo.

las plantillas deben mantenerse cerca del código que las usa por la misma razón que el código que funciona en conjunto debe mantenerse unido. las plantillas son una forma de código, la V en MVC. querrá plantillas de grano fino para permitir (re) usar. no hay razón para que la capa de presentación no sea tan SECA como otras partes del código.

Answer 2

Diría que MVC tiene más sentido para mí, ya que se siente mejor, pero la única diferencia práctica es que su login.php contendrá tanto el modelo (definiciones de estructura de datos) como el controlador (código para acciones de página). Podría agregar un archivo al módulo, por ejemplo, class.login.php y usar __autoload() para eso, lo que esencialmente implementaría una estructura MVC.

Answer 3

Escribir un marco podría ser una experiencia gratificante. Lo importante a tener en cuenta es que no se escribe un marco por sí mismo. La razón por la que uno escribe un marco es facilitar el desarrollo.

Dado que es un marco personal, debe pensar en términos de cómo podría ayudarle a desarrollarse con menos complicaciones.

No creo que un sistema de plantillas sea una buena idea. Piénselo: ¿cuál es el principal beneficio de usar un sistema de plantillas? La respuesta es que ayuda a los equipos con diferentes conjuntos de habilidades a desarrollar conjuntamente una aplicación. En otras palabras, algunos miembros del equipo pueden trabajar en la interfaz de usuario y no necesitan ser codificadores PHP. Ahora bien, un marco personal probablemente será utilizado por una sola persona y el beneficio del sistema de plantillas se vuelve irrelevante.

En general, debe observar sus propios hábitos y métodos de codificación y descubrir tareas que le lleven la mayor parte de su tiempo en un proyecto típico. Entonces debería preguntarse cómo puede automatizar esas tareas para requerir menos tiempo y esfuerzo. Al implementar esos mecanismos de automatización, tendrá que apegarse a algún tipo de convenciones (similar a una API). La suma de los mecanismos de ayuda y las convenciones será su marco personal.

Buena suerte.

Answer 4

También estoy escribiendo un framework php con un amigo mío. Absolutamente puedo entender lo que haces.

Creo que lo que estás haciendo es cerca de mvc. Tienes las plantillas como vistas. Y los módulos como controlador. Entonces creo que está bien. Lo único que necesitas es el modelo. Eso sería algún tipo de registros activos.

En mi marco, hay conceptos simulares, excepto que estamos escribiendo nuestro propio motor de registros activos en este momento. Creo que lo que haces no está mal. Pero es difícil de decir sin ver el código.

Solo veo un problema que debes resolver. Un marco debe estar perfectamente integrado. Siempre es complicado hacer que su módulo se vea bien integrado sin tener que pensar siempre en el módulo mientras está codificando la aplicación.

Answer 5

¿MVC es realmente efectivo para un marco personal?

Lo que MVC significa más, debido a su vaga interpretación, es la lógica de negocios, la presentación y el manejo de entradas. Entonces, a menos que intente diseñar una aplicación que no implique a tres de ellos, MVC es, en su vago sentido, muy adecuado.

Sin embargo, a menudo puede ser más formal de lo que usted desea, ya que exige la separación física de las ideas en diferentes archivos de códigos. Las tareas rápidas y sucias o la creación rápida de prototipos se pueden configurar más rápidamente si se evitan los trámites.

A largo plazo, lo que MVC solicita es beneficioso para la sostenibilidad de la aplicación en formas de mantenimiento, modificación o adición. No querrás perderte esto. Sin embargo, no todos los marcos fomentan las prácticas correctas. No me sorprende que encuentre que las diversas implementaciones que ha probado son insuficientes. Mi favorito personal es Agavi. Para mí y para otros, en un mundo de marcos PHP que no se sienten bien, Agavi surge para hacer las cosas correctas. Agavi vale la pena.

¿Sería una mala idea usar un sistema de módulos?

MVC le pide que separe los componentes de la lógica comercial, la presentación y el manejo de entrada, pero no sugiere cómo diseñar los archivos. Supongo que este es el desafío que está abordando con un sistema de módulos. Para responder a su pregunta: los módulos sirven de manera idéntica a los subdirectorios. Si los elementos son pocos, probablemente sea más complicado molestarse con los subdirectorios, incluso si los archivos se pueden separar lógicamente en ellos. Cuando la cantidad de elementos crece, ahora resulta engorroso localizarlos a todos y los subdirectorios se convierten en una mejor opción.

Frameworks abordará la funcionalidad que le permite tratar los módulos como su propia entidad configurable. La misma funcionalidad podría existir sin módulos, quizás en una casa más engorrosa. No obstante, no considere los módulos principalmente como un sistema. Los sistemas son tan vagos que puedes adaptarlos a la configuración que consideres adecuada.

¿Alguna vez escribiste un marco para ti? ¿Cuáles son tus experiencias?

Sí, he escrito varios marcos con varios enfoques para resolver los problemas de las aplicaciones web. Cada uno de esos marcos que escribí se convirtió en una curva de aprendizaje vital. En cada marco que hice descubrí más y más los problemas con la construcción de software. Después de no poder crear algo interesante, aún así gané porque cuando me pidieron que hiciera un programa, pude hacerlo completamente con justicia.

Te recomiendo que continúes si este es el tipo de experiencia de aprendizaje que deseas. De lo contrario, dale una oportunidad a Agavi. Si eso también falla, asegúrese de tener una especificación clara y detallada de lo que hará su marco. La forma más fácil de incursionar para crear software, trabajar realmente duro y no lograr nada es no decidir de antemano qué hará exactamente su software. Cada vez que me topé con la creación de código, lo único que tenía en mente era que lo haría bien . Lo que sucedió fue una historia diferente: oh, bueno, necesito hacer un sistema de enrutamiento ya que eso parece lógico; Hmm, está bien, ahora necesito un buen sistema de plantillas; bien, ahora es el momento de la abstracción de la base de datos; pero, vaya, qué mucho de pensar; Debería buscar el mismo sistema del software XXY para inspirarme. Ahí está el grito común que aboga primero por usar el software existente.

La razón por la que pensé que podía hacerlo bien no fue porque todos los aspectos prácticos del marco de trabajo se sentían mal. De hecho, no sabía nada de lo correcto o incorrecto que eran porque nunca trabajé con ellos. Lo que hice con el trabajo fue el esmalte, y se sintió poco firme. La forma más rápida de obtener su propio marco es robar los tornillos y tuercas de otro y diseñar su propio esmalte. Eso es lo que ves al construir una aplicación y francamente es la única parte que importa. Todo lo demás es una pérdida de tiempo en repetitivo. Sin embargo, para aprender a construir software, no es una pérdida de tiempo.

Si tiene cualquier otra pregunta, por favor pregunte. Me complace responder con mi propia experiencia.

Answer 6

¿MVC es realmente efectivo para un marco personal?

Si puede ser. Aunque puede ser un poco exagerado (lo cual no es necesariamente algo malo si estás tratando de aprender)

¿Sería una mala idea usar un sistema de módulos?

Esto nunca es una mala idea

¿Alguna vez escribiste un marco para ti? ¿Cuáles son tus experiencias?

Escribí un marco de seguridad común para las aplicaciones PHP de mi grupo cuando era pasante. Aprendí mucho, pero el proyecto en su conjunto podría haberse beneficiado más de una solución preconstruida.

Por supuesto, no habría aprendido tanto si acabo de instalar una solución preconstruida. Por lo tanto, siempre debe tener esto en cuenta, especialmente para proyectos personales. A veces, reinventar la rueda es la única forma en que aprenderás algo bien.

Answer 7

• ¿MVC es realmente efectivo para un marco personal?
• ¿Sería una mala idea usar un sistema de módulos?

Sí lo es. Pero MVC es un patrón de diseño tan flojo que permite trazar la línea entre el modelo, la vista y el controlador en cualquier lugar que desee. Para mí, las partes más importantes son el modelo y la vista. Simplemente tengo páginas, módulos php, que generan html rellenando una plantilla de una base de datos. Las páginas son la vista y la base de datos es el modelo. Cualquier código común específico de la aplicación se puede descomponer en "controladores". Un ejemplo podría ser una consulta común y sofisticada que varias páginas deben usar para representar datos.

Aparte de eso, tengo utilidades para el acceso seguro a bases de datos, plantillas simples y otras cosas.

• ¿Alguna vez escribiste un marco para ti? ¿Cuáles son tus experiencias?

Sí. Estoy muy contento de haberlo hecho. Puedo mantenerlo simple. Sé íntimamente cómo funciona. No dependo de nadie más que de mí mismo. Puedo mantenerlo simple pero útil.

Algunos punteros (0x912abe25 ...):

Cada abstracción tiene un costo.

No te apetezca. Puede lamentar no mantenerlo simple. Agregue la cantidad justa de abstracción. Es posible que te encuentres abstraído y que algo que debería ser simple se vuelva excesivamente complejo. Sé que cometí este error. Recuerda que no lo vas a necesitar.

Alcance bien sus variables

No cargue sus páginas haciendo

 include_once(''...page file ...'');

donde se espera que el archivo de la página tenga un montón de php en línea para ejecutar buscando diferentes variables globales. Pierdes todo sentido de alcance. Esto puede ser desagradable si carga su archivo de página desde el interior de una función:

 function processCredentials()
{
if (credentialsFail)
{
include_once(''loginpage.php'');
}
}

Además, cuando se trata del alcance, trate todo lo que esté conectado a las plantillas como variables con alcance. Tenga cuidado si completa las plantillas de algo que está fuera del archivo de página asociado con esa plantilla (como un master index.php o algo así). Cuando haces esto, no está claro exactamente qué se ha rellenado para ti y qué se requiere que conectes a la plantilla.

No sobre-modele su base de datos con OO.

Para un acceso simple a la base de datos, crea abstracciones útiles. Esto podría ser algo tan simple como ir a buscar una fila en un objeto por un índice primario.

Para consultas más complejas, no te intimides con SQL. Use abstracciones simples para garantizar la sanitización y la validación de sus entradas. No te vuelvas loco con abstraer la base de datos. BESO.

Answer 8

Refactoreé un gran proyecto de PHP para que sea más compatible con MVC.

Me pareció especialmente útil crear una capa DAO para centralizar todos los accesos a la base de datos. Creé una función daoFactory, que crea el DAO e inyecta el identificador de la base de datos en él (también el registrador, utilicé log4php, se inyectó).

Para el DAO, utilicé mucho las funcionalidades de la base de datos (mysql), como el procedimiento almacenado y los disparadores. Estoy completamente de acuerdo con Doug T. en evitar la sobre-abstracción, especialmente para el acceso a la base de datos: si usa el DB adecuadamente (declaraciones preparadas, etc.) no necesita ningún ORM y su código será mucho más rápido. Pero, por supuesto, debes aprender mysql (o postgress) y ser dependiente de él (especialmente si utilizas muchos procedimientos almacenados, como suelo hacerlo).

Actualmente, estoy refabricando un paso más allá, usando el framework Slim php y avanzando hacia una API apta para el resto: en este caso ya no hay vista porque todo se emite como json. Pero todavía uso smarty porque su almacenamiento en caché funciona bien y lo sé.