php - tutorial - Compromiso con Zend Framework: ¿algún argumento en contra?

zend server (6)

Estoy restaurando un gran CMS en el que he estado trabajando durante bastantes años. El producto en sí es excelente, pero algunos componentes, la Base de datos y las clases de traducción, por ejemplo, necesitan ser reemplazados urgentemente, en parte creados por ellos mismos en 2002, crecieron hasta convertirse en un caos en el tiempo y pueden tener problemas para sobrevivir a una auditoría de seguridad .

Por lo tanto, he estado observando de cerca varios marcos (o, más exactamente, bibliotecas de componentes, ya que no tengo la intención de cambiar la estructura básica del CMS) y terminé con mi gusto por Zend Framework. Ofrecen un modelo sólido de MVC pero no te obligan a hacerlo, y ofrecen muchos componentes profesionales que obviamente han recibido mucha atención (¿Sabías que hay múltiples plurales en ruso y no puedes traducirlos usando un simple ($number == 0) or ($number > 1) cambio no lo hice, pero Zend_Translate puede manejarlo. Solo para ilustrar el nivel de dificultad con que la biblioteca parece haber sido construida.

Ahora estoy literalmente en el punto de no retorno, comenzando a reemplazar los componentes clave del sistema por los hechos por Zend. Realmente no estoy dudando, y seguramente no estoy buscando incitar a una guerra de llama, pero antes de seguir adelante, me gustaría dar un paso atrás y ver si hay algo que habla en contra de atar un gran sistema de cerca a Zend Marco de referencia.

Lo que me gusta de Zend:

Por lo que puedo ver, código de muy alta calidad
Extremadamente bien documentado, al menos en lo que se refiere a las presentaciones de cómo funcionan las cosas (Todavía no se ha tenido que usar la documentación detallada de la API)
Respaldado por una compañía que tiene interés en ver prosperar el marco
Bien recibido en la comunidad, tiene una considerable base de usuarios
Emplea estándares de codificación que me gustan
Viene con un conjunto completo de pruebas unitarias
Me parece la opción correcta para hacer, o al menos una de las opciones correctas, en términos de desarrollo de PHP profesional y moderno.

He estado pensando en encapsular y abstraer la funcionalidad de ZF en sus propias clases para poder cambiar los marcos más fácilmente, pero he llegado a la conclusión de que no sería una buena idea porque:

sería un nivel innecesario de abstracción
podría costar el rendimiento
la gran ventaja de utilizar un marco de trabajo (la existencia de una base de desarrolladores que esté familiarizada con sus componentes) se cancelaría en parte

por lo tanto, el compromiso con ZF sería profundo. Por lo tanto, mi pregunta:

¿Hay algo sustancial hablando en contra de comprometerse con el Marco Zend?

¿Tiene conocimiento interno de los planes de Zend Inc. para hacer el mal en 2011 y convertirlo en una biblioteca de código cerrado? ¿Zend Inc. es ~~manejado por vampiros~~ manejados por vampiros malvados que quieren apoderarse de la tierra? (Se estableció en los comentarios que Zend en realidad está dirigido por vampiros.) ¿Hay fallas conceptuales en la base de códigos que comienzas a notar cuando haces la transición de todos tus proyectos a ella? ¿Es la apariencia del código de calidad una ilusión? ¿El código se ve bien, pero funciona terriblemente lento en cualquier cosa debajo de mi estación de trabajo de cuatro núcleos?

Aceptando respuesta
Muchas gracias a todos por sus comentarios detallados. Desearía poder establecer una recompensa y distribuirla de manera uniforme entre todos los contestadores.
Entre muchas opiniones favorables a ZF, había una muy bien fundada en contra. Me lo tomé muy en serio y eché un vistazo de cerca a las alternativas, principalmente Yii y Kohana. A partir de esa comparación y de leer algunas opiniones más sobre ZF y los productos de la competencia, puedo ver que Zend puede verse como inflado en algunos campos en comparación con marcos más minimalistas. (También puedo ver que este "abotagamiento" es principalmente una buena razón para proporcionar la máxima flexibilidad. Pero la pregunta de si desea la máxima flexibilidad y lidiar con la complejidad resultante, o un enfoque más simple con pautas claras, es válida).
De todos modos, iré por Zend para el proyecto en cuestión, porque el uso principal que tengo para el marco es como una biblioteca de componentes . No quiero adoptar el modelo MVC de Zend, solo necesito componentes de alta calidad para internacionalización, manejo de sesiones, etc. Como estoy construyendo un producto redistribuible, la flexibilidad de Zend (por ejemplo, el soporte para cinco formatos diferentes de diccionario) es bienvenida. Además, ZF parece ser el único marco que permite el grado de libertad que quiero (sin uso forzado de patrones, estructuras de archivos ...) por lo que puedo ver, ningún otro marco ofrece eso.
Sin embargo, para futuros proyectos en los que deseo utilizar las características MVC reales y someterme por completo a las convenciones de un framework sobre creación de aplicaciones, nombres, estilo y procedimientos, no necesariamente iré por Zend, sino por un sistema más minimalista. marco como Yii o Kohana.

A menos que esté esperando un proyecto gigantesco y masivo con más de 20 desarrolladores, yo, si fuera usted, haría cualquier cosa, incluso sacrificar un brazo y / o una pierna solo para evitar Zend Framework .

La buena opción que descubrió podría ser útil, hasta el punto en que encuentre otra configuración de 1k + que simplemente parezca una pérdida de tiempo y esfuerzo de los desarrolladores en la biblioteca. Pronto se encontrará en medio de Customization Ocean, abrumado por configuraciones, interfaces y clases abstractas.
La documentación no solo está detallada, sino que es muy larga y complicada (de forma similar a la biblioteca). Quiero que las clases de la 3ª parte me ayuden y no se interpongan en mi camino.
El factor más importante fue la velocidad de desarrollo para mí, obviamente. Sin un grupo de universidades a su alrededor, Zend Framework debe considerarse seriamente si se descarta.
Hay demasiadas personas haciendo deseos en el rastreador de problemas de Zend, demasiadas personas que implementan el código. Hasta la fecha, aún no he visto ninguna visión seria detrás de esos millones de líneas.

Mis dos centavos realmente se reducen a un punto: a pesar (o más bien, ¿por qué?) Está respaldado por la compañía PHP, está demasiado hinchado para uso personal y para proyectos pequeños y medianos.

Mi equipo actualmente usa Yii para un proyecto de tamaño mediano. Tampoco es perfecto, pero es mucho más útil y amigable para el desarrollador en comparación con el hermano mayor.

Hemos estado desarrollando con ZF durante casi un año, y realmente no tengo grandes dudas al respecto. Tuve un poco de una curva de aprendizaje, pero una vez que lo entendí, me di cuenta de lo bien que se armó realmente este marco.

En comparación con otros marcos, algunas personas podrían señalar la falta de una biblioteca de modelos como un inconveniente. De hecho prefiero que no me digan qué usar, e integrar Doctrine con ZF no tiene fricción. Si está desarrollando en PHP 5.3 y quiere un ORM, recomendaría Doctrine 2 (advertencia: todavía está en pruebas alfa).

La otra gran cosa es poder escoger y elegir lo que quieres o no quieres. No soy un gran admirador de Zend_Form, pero no tengo que usarlo si no quiero. Además, existe una arquitectura de complementos estructurada de forma muy flexible que permite conectar fácilmente sus propias bibliotecas al marco.

Entonces, soy un gran admirador de eso.

No tengo ningún gran argumento en contra de ZF, al contrario; por supuesto, todavía no he usado todos los componentes (no estoy seguro de que alguien lo haya hecho) , pero nunca he visto nada que parezca "malo" cuando reviso las fuentes.

Cuando empiezo un nuevo proyecto, en general, me voy con Zend Framework, en realidad, si soy yo el que tiene que elegir ...

Hay al menos un argumento que me gustaría agregar a su lista:

Zend Framework puede integrarse con otros componentes: usted habló sobre el uso de componentes de ZF en su aplicación, pero no habló de lo contrario.
- Un gran ejemplo es Doctrine (el ORM predeterminado de Symfony) , que se puede usar con ZF con bastante facilidad, y es mucho mejor que Zend_Db , en mi opinión.

Además de eso, debo decir que estoy de acuerdo con todos sus puntos.

Acerca de encapsular las clases de ZF en sus propias clases: sí, podría hacer eso (a veces lo hago) , pero no recomendaría hacerlo para todo: en la mayoría de los casos, probablemente no sea necesario.

Acerca del futuro :

Zend Framework se publica bajo una licencia BSD, lo que significa que lo que existe no se puede cerrar.
Cerrarlo significaría su fin, de todos modos, sería un movimiento estúpido, en el contexto de la comunidad PHP
El trabajo en ZF 2.0 acaba de comenzar (con PHP 5.3 como requisito, por cierto)
- Tal vez, dependiendo de su agenda para su aplicación, podría ser interesante?
- Al menos si no necesitas comenzar a desarrollar antes de al menos un par de meses ...

Una cosa que me falta en Zend Framework es un asignador OR correcto. Zend_DB está bien, pero tiene algunas deficiencias, especialmente cuando se trata de enormes bases de datos (muchas tablas) se vuelve muy engorroso. Pero hay un par de mapeadores OR que pueden integrarse (por ejemplo, zend-framework-orm o Doctrine tal como lo menciona Pascal MARTIN).

Pero sí, Zend es excelente, muy poderoso y creo que es en cierto modo lo que PHP debería ser / debería haber sido en términos de interfaz y funcionalidad.

Lo que más me gusta aparte de lo obvio es el soporte para Dojo para aplicaciones de cliente enriquecido y el soporte SOAP .

Usé ZF en un proyecto como único desarrollador. Aunque la curva de aprendizaje fue bastante empinada, no encontré muchos de los problemas descritos anteriormente. En general, encontré que el marco era muy flexible, y el acoplamiento libre de los componentes me facilitó hacer lo mío cuando la forma de hacerlo de ZF no se ajustaba a mis necesidades.

Pero después de haber comenzado a usar Python recientemente, yo diría que usar Python;)

Zend Framework es la mejor opción . Mejor API marco de todos ellos, código legible, convenciones de lenguaje, buenos documentos, comunidad, soporte y todo
Mis aversiones (subjetivas, las personas mabe me van a rechazar) son:

Zend_Form , tiene su uso, pero en general es demasiado molesto, solo quiero estructurar mi HTML, no luchar contra las API y los decoradores.
Zend_Db_Table , poderoso, pero necesita mucho trabajo para lograr tus objetivos, y Rails me enseñó a ser flojo. No, no quiero escribir 3 clases para un modelo, una para la tabla, una para el conjunto de filas, una para la fila, luego unirlas entre sí, y así sucesivamente. Es posible que necesite la puerta de enlace de datos de la tabla en algún momento, pero por ahora quiero conectar esta información con un registro activo rápido.
sin registro activo. Con el enlace estático tardío en php 5.3 esto podría cambiar ...

Intenté realmente usar estos dos durante un par de meses hasta que finalmente lo tuve.

Los superé (ideas de Ruby on Rails)

utilice ayudantes de vista simple en lugar de Zend_Form como en:
echo $this->formText(''email'', ''[email protected]'', array(''size'' => 32));
tener mi propio Active Record como modelos ( http://www.phpactiverecord.org )
validar y filtrar en el modelo
para los casos de esquina realmente extremos, uno puede recurrir a Zend_Form + Zend_Db_Table, aunque nunca sentí la necesidad.

EDITAR
Hay algunos niños nuevos que vale la pena visitar, como Laravel

Lo único que ZF realmente gana con respecto a otros marcos es el enrutador, el controlador y las vistas, las convenciones, el código limpio y legible, el proceso.