entre Desarrolladores

Recibe ayuda de expertos

Registrate y pregunta

Es gratis y fácil

Recibe respuestas

Respuestas, votos y comentarios

Vota y selecciona respuestas

Recibe puntos, vota y da la solución

Pregunta

1voto

Trabajar con frameworks, por qué¿?

Bueno, después del consejo de @carlossevi otra pregunta nueva. Creo que es buena idea el uso de frameworks ya que facilitan enormemente las tareas de los programadores y además ayudan a que la comunidad crezca si contribuyes además de utilizarlos.

Es por esto que voy a probar con CodeIgniter pero antes de nada me gustaría hacer una pregunta a los gurús de la sala; cómo definiríais exactamente un framework y cual es exactamente su cometido? Se podría definir como una plantilla (asemejándose a Joomla por ejemplo) totalmente personalizable y no automatizada? O cómo lo definiríais para una persona inexperta y que nunca a tratado con ellos?

3 Respuestas

2votos

carlossevi Puntos63540

Lamento aburrirte contestando siempre yo, pero ahí voy =)

Un framework es un marco de trabajo, un conjunto de herramientas que utilizar a la hora de programar una aplicación, en este caso una aplicación web escrita en PHP. Como he leido por ahí es "Un conjunto de librerías que una vez aprendida a utilizar nos facilitan el trabajo, ya que nos brindan una cantidad de códigos que nos evitan el reescribir una y otra vez los mismos script".

Motivos por los que utilizar un framework:

  1. No reinventar la rueda. ¿Para qué intentar resolver un problema que ya ha sido resuelto por programadores con más experiencia que nosotros que presumiblemente lo habrán resuelto de manera más óptima que nosotros?
  2. Reutilización de código. Evitamos reescribir una y otra vez lo mismo minimizando errores y tiempo de desarrollo.
  3. Forzar el uso de buenas prácticas de programación y patrones de arquitectura de software adecuados.
  4. Suelen adoptar un sistema de plantillas que facilita enormemente la separación del trabajo entre programadores y diseñadores además de facilitar actualizaciones futuras.
  5. Es más fácil encontrar alguien en la comunidad que nos de soporte porque nuestro código estará más estandarizado.
  6. Normalmente pueden extenderse para añadir funcionalidades concretas que tengamos, y lo mejor es que seguro que hay alguien que ha tenido esa necesidad antes que nosotros y podemos aprovecharnos de su conocimiento y/o implementar librerías de terceros (Por ejemplo, trabajar con MS Excel, generar PDF, envío de correos...).

Respecto a la elección del framework concreto yo ya te he contestado por ahí en otros sitios así que simplemente te voy a dejar esta conversación que es bastante interesante: http://betabeers.com/forum/cual-es-el-mejor-framework-php-110/

Este comentario me parece muy acertado:

Sin duda te recomiendo Laravel, he probado la mayoría de los frameworks php, normalmente prefiero trabajar con ruby, pero si tengo que trabajar con php en algún proyecto uso Laravel siempre.
Symfony me parece un poco grande... y es recomendado solo si vas a trabajar en proyectos grandes.
FuelPHP no esta mal aunque cuando intente trabajar con el en su version 1.4 tenia demasiados bugs.
CakePHP simplemente no me gsuta... me parece que se quedo en el pasado.
Yii framework esta bastante bien, lo he usado en varios proyectos incluso en el desarrollo web de una revista, esta bien aunque comparado con laravel deja mucho que desear.
Codeigniter : la documentación es excelente y me gusta bastante. Aunque sigue gustándome mucho mas el framework Laravel.
PhalconPHP es bastante bueno, y se esta hablando mucho de el, aunque desde mi punto de vista ahun esta un poco verde.

0voto

ankeorum comentado

Carlos gracias por contestar con tanta presteza y de manera tan acertada. En absoluto me molesta es por eso que te dije si podíamos hablar por mail ;)

1voto

Leonardo-Tadei Puntos227010

Hola ankeorum,

quería también responder a tus preguntas para aportar algunas cosas, ya que si bien la respuesta de @carlossevi es amplia y correcta, algunas de las definiciones que usa también se aplican a bibliotecas (librerías) que no son lo mismo que los frameworks.

La definición de framework es "un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar." El artículo al respecto en Wikipedia es una introducción bastante buena

Cuál es su cometido? El servir de estructura a problemas de índole similar y de manera específica. Es decir, que un framework debe resolver un tipo de problema específico. Es por esto que encotnrarás frameworks de autentificación, de validación, de generación de HTML, de persistencia, de comunicación, etc. Si un framework dice que soluciona varios problemas distintos o su alcance es demasiado general (como los "frameworks para desarrollo de aplicaciones web". Qué web? La de un banco? la de una tienda? la de una plataforma de educación a distancia?) yo, a priori, los miro con desconfianza.

Se podría definir como una plantilla? No, en el sentido que una plantilla habitualmente cambia cómo se ve una web, pero no provee funcionalidad, sino que es una cuestión visual. Por otra parte Joomla! no es una plantilla, sino un Sistema de Gestión de Contenidos que puede tener aspectos distintos según la plantilla (template) que elijas.

Usar un framework implica muchas cosas:

  • identificar tu problema correctamente para ver si algún framework existente soluciona ese tipo de problema en particular. Es habitual que una aplicación use varios frameworks si tiene varios problemas que resolver. Por ejemplo el IDE Eclipse está cosntruido usando 11 frameworks según sus autores.

  • escalar una curva de aprendizaje muy empianda. Los frameworks no son fáciles de usar; si bien cosas triviales se hacen en 10 minutos siguiendo un tutorial, hacer cosas más interesantes requiere estudiarlos mucho, leer mucha documentación y hacer muchas pruebas. Como corolario de esto, vas a ver que es raro que alguien domine varios frameworks... y el que conoce bien uno no quiere aprender otro y volver a sufrir la curva de aprendizaje.

  • la arquitectura la definirá el framework y no vos. Como la aplicación se organizará alrededor de los recursos que el framework proveerá, tendrás que conocer y aceptar la arquitectura que tenga el framework que uses. Por esto a veces no se pueden usar dos frameworks juntos si están pensados para diferentes arquitecturas aunque cada uno resuelva uno de los problemas que tenés.

  • inversión de control, también llamado principio de Holliwood. Esto significa que tu código será usado por el frameworks y no al revés, que parecería lo más natural a un novato, que tu código use el framework. Hay programadores a los que esto les parece inadmisible y por eso no usan frameworks si pueden evitarlo, y hay muchas personas que usan frameworks y no son concientes de que dejan de controlar el flujo de ejecución y todo lo que esto implica (bueno y malo)

  • no garantizan que uses buenas prácticas de desarrollo. Si bien el framework suele ser una pieza de código muy cuidada y que sí está construido usando buenas prácticas de programación, no hay como garantizar que el código que vos escribas sea bueno. Por poner un ejemplo, Hibernate es un excelente framework de mapeo objeto/relacional para Java, pero se podría "usar" solo para hacer las conexiones a la DB y luego escribir tus propias querys, cosa que no tiene nada que ver con la intención de Hibernate ni con el problema que soluciona (el mapeo objeto/relacional) ni es una buena práctica.

  • Extender para usar. Si el framework es de caja blanca, tendrás que comprender cuales son sus clases (porque generalmente usan el paradigma de Programación Orientada a Objetos) y extenderlas vía herencia para especializarlas y que hagan lo que tu aplicación necesita. El framework no es ejecutable, sino que lo que será ejecutable serán tus clases concretas que especializan el comportamiento. Generalmente se requiere el código fuente para poder usarlo.

  • Composición y delegación. Si el framework es de caja negra no hace falta un conocimiento profundo de cómo funciona, ya que se adecuá su comportamiento por configuración, composición o delegación. Esto implica que tenés que usar su funcionalidad dentro de los parámetros que concibió el diseñador lo que los hace un poco menos flexibles.

Hay más cuestiones, pero estas me parecen las más relevantes.

Por otra parte, existen también las bibliotecas (del ingés library), que son colecciones de funciones o procedimientos que asisten para resolver pequeñas cuestiones, como hacer conversiones, cálculos, conectarse con bases de datos, etc. Las bibliotecas sí son usadas por tu código y generalmente son llamadas con algunos parámetros que hace una sola tarea y devuelven un resultado concreto. Por ejemplo las funciones mysqli* de PHP son una biblioteca para trabajar con MySQL, las funciones imap* de PHP son para manejar correo electrónico, y así sucesivamente.

Conclusión: el uso de frameworks es una excelente estrategia si tenemos un problema específico y hay uno que lo resuelve. Generalemente es un problema grande o complejo.

Si la aplicación a desarrollar es chica, o no se identifica claramente el problema a resolver, o no se tiene el tiempo para aprender a usar un framework, una(s) biblioteca(s) debería ser más que suficiente para no reinventar la rueda y facilitarte la vida no teniendo que pensar cómo se resuleven pequeños problemas laterales del desarrollo.

Para ir a hacer las compras al supermercado voy en el auto, no en un camión de 18 ruedas. Ambos vehículos sirven para esa tarea y seguramente el camión será más robusto, me permitirá hacer más kilómetros durante su vida útil y traer a casa compras sin importar el tamaño ni el peso... pero claramente no es el vehículo más adecuado para esa tarea.

Hay que usar herramientas de terceros (no iria caminando al supermercado si puedo evitarlo), pero hay herramientas más idóneas que otras para algunas tareas.

Podemos seguir conversando en un hilo aparte sobre problemas concretos que tengas que resolver, para sugerirte herramientas y orientarte.

Saludos cordiales!

1voto

burzumumbra Puntos650

Pues si lo quieres corto, un Framework no es una plantilla, es mas como un contenedor de objetos. Si quieres usar un boton llamas a la clase ".boton" si quieres un boton rojo llamas a la clase ".boton . rojo". Así te ahorras el trabajo, claro estoy usando como ejemplo una semantica X de un framework X de CSS. Ademas de eso la mayoría de los frameworks te permiten personalizarlos. Y dirás yo puedo hacer eso reciclando CSS de mis otros proyectos, pero yo te digo no creo podas reciclar mas de 1000 lineas de código de manera ordenada, así como si nada.

Por favor, accede o regístrate para responder a esta pregunta.

Otras Preguntas y Respuestas


Actividad Reciente

...

Bienvenido a entre Desarrolladores, donde puedes realizar preguntas y recibir respuestas de otros miembros de la comunidad.

Conecta