php - usar - ¿Por qué Zend Framework es tan popular?

zend framework doc

Question

No soy un troll y mi objetivo no es comenzar una guerra de fuego; tampoco pretendo faltarle el respeto a los autores del Zend Framework: hay mucho trabajo fino en él. Pero ... Tengo un trabajo que hacer y me está costando conciliar la popularidad de ZF con la realidad de crear aplicaciones con ella. Realmente me gustaría saber de otros por qué usan Zend Framework.

Soy bastante nuevo en el mundo PHP, pero he hecho mucha programación en muchos idiomas. Después de leer muchos tutoriales y crear un par de aplicaciones en él, algunas instalaciones centrales de Zend Framework se sienten como código alfa para mí. En mi opinión, las siguientes debilidades fundamentales, entre otras, parecerían demasiado abrumadoras para considerar la implementación de aplicaciones, pero una y otra vez ZF se sugiere como uno de los mejores, si no el marco principal.

Primero permítanme decir que encuentro que gran parte de ZF es viable. El enrutamiento funciona prácticamente como debería, la instalación de Layout es útil (aunque muy diferente de los sistemas de plantillas como JSP / ASP), como lo es la función de caché, etc. Parece haber una tendencia en la comunidad a rellenar muchos modelos (por ejemplo, validación) y lógica de vista (ej. $ this-> headScript () - ¿por qué mi controlador debe preocuparse por qué archivo js requiere mi vista?) en los controladores, pero podría ser una cuestión de uso y no necesariamente la falla del marco.

Ahora, por un par de debilidades realmente serias (IMO) que he experimentado en mi corto tiempo con eso. Me estremezco al imaginar las otras áreas que descubriré en el futuro si sigo construyendo con ella.

1. Diseño de formulario
Muchas personas parecen estar descontentas con la falta de control sobre el diseño del formulario. ¿Cómo puede tener un marco popular donde la construcción de una forma simple requiere tanto debate? Pregunta 1 y pregunta 2 .

2. Autenticación / Autorización
Nadie realmente parece entender cómo simplemente realizar la autenticación / autorización de rutina. Las personas [incluido el tuyo en verdad] tienen dificultades para implementar un control de acceso simple. Además, el enfoque parece apoyarse en la serialización para la persistencia, en lugar del almacenamiento de base de datos tradicional de usuarios y permisos. Un ejemplo confuso , una propuesta para mejorar la instalación , un tutorial - parte I , y parte II . Esto es demasiado trabajo chicos!

¿Mis debilidades percibidas no son reales o de alguna manera no son un problema? ¿Por qué o por qué no? ¿Por qué eligió Zend Framework (o no)? ¿Hay otras áreas que te parezcan tan dolorosas como para querer volcar ZF para un enfoque diferente? Gracias por tus opiniones

Answer 1

Además de las respuestas anteriores, vale la pena mencionar que en un grupo reciente en DZone titulado ¿Qué marco de PHP usarías hoy para una nueva aplicación? , Zend Framework fue seleccionado como el más preferible para nuevos proyectos.

Answer 2

Bueno, somos desarrolladores porque se supone que podemos escribir "algunos" de nuestro propio código, ¿no? Se supone que los marcos no son asistentes, solo una ayuda adicional.

Answer 3

Coloreéme UNIMPRESSED con ZendFramework. Usar Zend Framework es como soldar un conjunto de ruedas de entrenamiento a tu código. Cualquier cosa que puedas hacer en Zend Framework es algo que puedes hacer en PHP sin formato. (Recuerde que ZF se escribió en PHP sin procesar). Y generalmente puede hacerlo con la misma cantidad de líneas de código, escritas en un estilo consistente con el resto de su aplicación. Y, al usar código PHP nativo, no estás encerrado en una herramienta de nicho que solo usan una minoría de desarrolladores de PHP. Y no tiene que preocuparse por la compatibilidad con los cambios en las versiones de ZF.

En mis aplicaciones, hago las mismas cosas que las herramientas de ZF, principalmente mediante el uso de funciones PHP simples que han existido durante años:

• validar los datos del formulario
• limpiar entrada de formulario
• manejar archivos cargados a través de formularios
• manipular y comparar fechas
• manejar la autenticación
• enviar correos electrónicos
• escribir en archivos de registro
• leer desde archivos de configuración
• leer páginas HTTP externas
• intercambio en formatos JSON y SOAP
• trabajar con API de terceros

No encuentro mucho en Zend Framework que valga la pena. Y no me haga comenzar a utilizar marcos de "andamiaje" dominantes como CodeCoffin, AppShackler o Ruby in Chains.

Answer 4

No elegí Zend Framework porque en el momento en que estaba evaluando frameworks PHP no era una solución completa e integrada para construir aplicaciones web. Elegí Symfony y desde entonces nunca tuve la necesidad de cambiar a otra cosa.

No estoy seguro si es lo mismo hoy en día, pero siempre pensé en ZF como una biblioteca de componentes en lugar de un marco. Un marco tiene reglas un tanto más estrictas para hacer las cosas y, a menudo, tiene herramientas de soporte mejor integradas para ayudar a las personas a hacerlas. Una biblioteca de componentes es más flexible en este sentido. Cuando las reglas del marco corresponden a los requisitos de la mayoría de las aplicaciones en el dominio del marco, yo mismo claramente prefiero esta solución. Este ha sido el caso con Symfony para mí. Utilizo ciertos componentes de ZF según sea necesario, pero nunca base mis proyectos en ZF.

Answer 5

No es necesario usar Zend_Form o Decorators. Puedes simplemente usar formularios HTML simples y luego dentro de Controller = Actions usa Zend_Filter_Input de esta manera. Así que tienes lo mejor de ambos mundos.

public function indexAction()
    {
        $this->view->title = ''Search Results'';

        $filters = array(''q'' => array(''StringTrim'' , ''StripTags''));
        $validators = array(''q'' => array(''presence'' => ''required''));

        $input = new Zend_Filter_Input($filters, $validators, $_GET);

        if ($input->isValid()) {
            $this->view->messages = '''';
            $q = $input->getEscaped(''q'');
            $this->view->q = $q;

            // do search
            try {
                $index = News_Search_Lucene::open(
                    SearchIndexer::getIndexDirectory());

                $results = $index->find($q);
            } catch (Exception $e) {
                $results = array();
            }

            $this->view->results = $results;

        } else {
            $this->view->messages = $input->getMessages();
        }
    }

Answer 6

No estoy seguro si ZF es realmente el framework PHP más popular. Lo elegí después de compararlo con otros marcos que hacen más cosas "mágicamente" porque todos parecían difíciles de personalizar.

Creo que ZF es un buen framework PHP MVC orientado a objetos, pero no estoy de acuerdo con algunos enfoques de ZF. Por ejemplo, solo uso Zend_Form para filtrar y validar datos. Todas las cosas de HTML y presentación se realizan en scripts de vista. El CSS es el responsable del diseño. Si necesitamos algunos cambios, la mayor parte del tiempo solo cambia el CSS. Si necesito hacer que el mismo formulario aparezca en muchas páginas, lo uso como una secuencia de comandos de vista parcial.

No me gusta tener que escribir un Mapper para cada Modelo y crear una subclase Zend_Db_Table para cada tabla de base de datos. En cambio, estoy investigando cómo usar otros patrones para el acceso a datos, o tal vez Doctrine.

Lo que no me gusta de Zend_Acl es que almacena la información ACL en el archivo ACL. Me gustaría almacenar esa información en la base de datos.

Lo bueno de este marco es que es fácil hacer las cosas a tu manera.

Answer 7

Uno de los principales beneficios de ZF es que puede tomar cualquiera de sus componentes y vincularlos fácilmente con su propio marco (o de un tercero) con modificaciones mínimas.

Answer 8

Utilizo ZF por varias razones: el host de clases ingeniosas, la carga lenta de clases, el uso independiente de clases y la fuente limpia y clara. La primera vez que lo usé, necesitaba construir un sistema de ACL, uno muy grande y complejo. Zend_Acl ayudó muchísimo.

Creo que ZF necesita trabajar en sus clases de docs y db. Los problemas de las clases de db tienen mucho que ver con PHP. Entonces quizás sea algo que Zend quiera investigar.

El OP es nuevo para PHP. Acepto que PHP tiene sus fallas, como la denominación arbitraria de funciones, pero en general tiene sentido para HTTP y no oculta la realidad.

Answer 9

ZF es un buen punto de partida. Utilicé zend_tool para generar un esqueleto MVC de mi aplicación de tamaño mediano y usé muchos otros componentes (Zend_Cache, correo electrónico, traducir, formularios, sesión).

Y acepto que el diseño de formularios es complicado si intentas hacerlo como dice Zend, con decoradores. Hay formas de usar solo elementos Zend_Form con validación y en su diseño personalizado, sin decoradores.

Tuve una mala experiencia con Zend Cookies. Simplemente no pude establecer una cookie para todo mi dominio. El viejo buen setcookie hizo bien el truco.

Acerca de Acl: una vez más, los ejemplos en la documentación de Zend y Zend_Acl no funcionan bien a veces. Usé el enfoque del complemento Controller y mi propia "gestión de recursos basada en funciones" para controlar los permisos.

Ni siquiera intenté con Zend Data Gateway, usé Doctrine (supongo que es porque me gusta nHibernate :)) y la conexión de Doctrine fue muy fácil.

Creo que ZF es bueno porque puedes usarlo como quieras. Creo que sería más difícil con algunos otros marcos.

Answer 10

Diseño del formulario:

Es realmente fácil. Los decoradores son un dolor en el trasero durante tu primer contacto con ellos, solo son magia negra. Entonces te das cuenta de lo útiles que son y de que puedes hacer casi cualquier cosa con ellos. Cuando finalmente llegas a un punto donde los decoradores no son suficientes, puedes simplemente renderizar elementos de formulario separados en tu vista o incluso escribir tu propio formulario HTML. Considera este ejemplo:

formar

$text = new Zend_Form_Element_Text(''text'');
$text->addValidator(''NotEmpty'')->setRequired();
$submit = new Zend_Form_Element_Submit(''submit'');

ver

<form>
<input type="text" id="text" name="text" />
<input type="submit" id="submit" name="submit" value="Send" />
</form>

controlador:

$form = new Form_Whatever();
if ($this->_request->isPost()) {
    if ($form->isValid($this->_request->getPost()) {
        // code
    }
}

Ahí tienes. Tiene un formulario, escribió su HTML manualmente, pero aún se beneficia de la validación intrínseca de ZF. ¿Por qué? Porque aún crea el objeto de formulario en el controlador y lo alimenta los datos enviados a través de POST. Todavía obtienes tus filtros, validadores, cualquier cosa que quieras. Con cualquier HTML que quieras. Y también puedes conectar una vista externa al formulario si quieres ir a extremos :).

Oh, por cierto, ¿sabías que tus formularios son reutilizables? Sí, puedes escribir un formulario y usarlo en varios lugares. Sin molestia. Eso es lo que personalmente me gusta de las formas en ZF (y desagrado en CodeIgniter, que es un gran marco también, por cierto).

Autenticación:

Zend Framework: hash de contraseña de inicio de sesión, validador de correo electrónico?

Sí, es solo una pequeña porción de código. Básicamente, cópielo y péguelo en sus proyectos.

En cuanto a ACL, solo debes crear tus reglas y luego consultarlas cuando las necesites. Un trazador de líneas. No puede ser mas simple

Personalmente, creo que ZF es popular porque simplemente ahorra dinero. Si me pones al frente de un proyecto, puedo garantizarte que lo terminaré dos veces más rápido si me permites usar ZF en lugar de otro marco que conozco. Y probablemente una fracción del tiempo necesitaría hacer todo en PHP de referencia. Entonces eso es todo: ahorrar tiempo = ahorrar dinero. O ganarte dinero extra, pero cualquiera de las dos reglas, ¿verdad?

Answer 11

Formularios: el enfoque del decorador es complicado, pero a prueba de balas y no tiene precio para aplicaciones con muchas formas. No le importa si tiene 10 o 25 elementos en su forma, el estilo es siempre el mismo. Le ahorra una gran cantidad de trabajo cuando sabe cómo usarlo. Para los usuarios con mentes y objetivos más simples siempre existe el decorador viewScript;)

Auth / Acl: Nunca tuve ningún problema con estos.

Zend_Auth::getInstance()->hasIdentity() //logged in

y

Zend_Auth::getInstance()->getIdentity()->role; //returns admin

Para Acl:

$acl->isAllowed($who,  $where, $what);
$acl->isAllowed(''roleAdmin'', ''resourcePosts'', ''create''); //returns true

Se puede modificar fácilmente para que coincida con MVC:

$acl->isAllowed(''roleAdmin'', $module.ucfirst($controller), $action); //returns true
$acl->isAllowed(''roleAdmin'', ''adminPosts'', ''create''); //returns true

Answer 12

Porque son buenos en Marketing

Los fundadores de Zend, Andi Gutmans y Zeev Suraski, son colaboradores clave de PHP

Y tienen uno de los frameworks más completos para php.

Cuando lo piensas; es como decir:

"Nuestro lenguaje no es tan eficiente como podría ser, así que hicimos un marco con almacenamiento en caché que lo hace más rápido"

• La mayor parte de lo que ofrece Zend, se puede hacer sin Zend.
• Pero el paquete de Zend es una muy buena distribución "todo en uno".
• Ofrecen certificaciones y entrenamientos.

Answer 13

Simplicidad para construir aplicaciones de tamaño mediano. Hasta ZF, tuviste que construir tu propio "framework" para hacer aplicaciones de tamaño mediano. Ahora es mucho más simple.

No creo que el desacoplamiento y los elementos simples que se pueden usar de forma independiente sean la clave del éxito. Es una buena característica, pero no es el uso regular.

El soporte y el tamaño de la comunidad son relevantes en el equilibrio con otros marcos.

En términos de velocidad, NO son mejores que otros marcos.