Cita: Creo que lo que te deberías estar preguntado es si en realidad OOP es lo que te favorece para realizar tu proyecto.
OOP tiene ventajas, la programación procedimental también las tiene, pero digamos que cada una tiene su espacio, cada una busca cumplir con las necesidades de un proyecto en particular, sin embargo no significa que OOP es lo mejor para todo proyecto existente, ni tampoco que programación procedimental es lo mejor para todo proyecto existente.
Estimado Acron, veo que más abajo usas el término "cliché", pero prefectamente se aplica a lo que dices sobre POO versus Procedural. No tiene mayores ventajas no hacerlo POO, es fundamentalmente un tema de diseño y organización de un sistema, en casos disparatadamente contados se podría hablar de diferencias de rendimiento, pero con los lenguajes de hoy día es casi ridículo hablar de diferencias o de necesidad de "optimizaciones extremas" (como cambiar la forma de incrementar variables, etc).
Cita: El hecho de que PHP sea híbrido te da mucha más ventaja, "si se necesita" se puede aplicar OOP en algún módulo y procedimientos en otro lugar.
En lo personal lo considero una desventaja, principalmente por lo anterior expuesto, mucho de la filosofía "opcional" o "híbrida" pasa por el "no entendimiento" de cómo funciona la POO. PHP debería ser como Java, 100% POO donde no hay forma de programar sin hacer clases.
Cita: Yo soy muy práctico a la hora de decidir entre uno y otro, simplemente elijo el que me funcione mejor para llevar a cabo lo que deseo hacer, no hay razón para usar otra cosa "porque es mejor" si en realidad no hace falta.
No veo diferencias de estrategia entre usar "procedural" y "poo".
Cita: Ahora, si en realidad crees que debes usar OOP para tu proyecto, no es necesario tampoco usar MVC.
En este punto sí estoy de acuerdo, MVC no es sinónimo de POO ni de 3 capas, necesariamente.
Cita: MVC es un patrón de diseño, como factory y singleton, pero no una escencia de OOP, tiene sus ventajas pero debo decir que con el tiempo e irónicamente, el desarrollo que ha tenido, dista mucho de lo que alguna vez fue la idea inicial.
¿Que ha tenido quién? ¿El patrón o algún producto MVC? Son cosas distintas y no queda claro lo que dices.
Cita: El separar presentación de lógica es genial, pero en el caso de MVC, ha crecido tanto que en muchos casos rompe con la idea original y no facilita tanto como se pensó el mantenimiento por parte de varios programadores.
No tiene sentido lo que dices, entre varios programadores o en el trabajo con diseñadores?
Cita: La idea general era, mediante una plantilla, el diseñador o programador web (alguien únicamente dedicado al código html) podía hacer los cambios necesarios sin necesidad de estar mirando lo que ocurre con el código de servidor (php, aspx, jsp....)
¿La idea general de quién?
Cita: Sin embargo, el montar el sistema base de un MVC no es tan simple, aún utilizando cosas como smarty y en muchos casos solo genera pérdidas de tiempo en desarrollo lo cual afecta mayormente a los que tienen fechas de entrega.
Estás entrando en una falacia. Desarrollar sistemas no necesarimente tiene que ver con un problema particular de cómo integrar diseñadores en el trabajo de realizar una interfaz. El problema que le ves es porque estabas en lo personal acostumbrando a tener diseñadores tocando plantillas y tus programadores tocando el código interno, pero que no lo puedas hacer con MVC no es un problema del patrón, es de tu forma de trabajo.
Diseñen aparte e integren luego la estética. Desarrollar sistemas no es solo tener a los diseñadores tocando directamente el código de la presentación.
Cita: Dependiendo como lo veas, sería tonto cambiar un archivo por un archivo de plantilla tpl, un archivo encargado de procesar la lógica y un archivo encargado de interconectar a los otros dos.
Como aclaré en el punto anterior, esto es un tema particular de organización del equipo de trabajo, sus procesos e integración, no de POO ni de MVC.
Cita: Para muchos es un cliché el decir que OOP y en este caso MVC, tiene beneficios cuando son varios programadores los que estarán trabajando en conjunto para desarrollar el proyecto, pero eso es en realidad lo que termina pasando en la mayoría de los casos, es allí donde ves un beneficio, y si eres único programador, ves un beneficio cuando sabes que crearás proyectos a futuro en los cuales el reutilizar códigos será un hecho.
Este comentario es equivocado, vuelves a caer en lo mismo, lo que tienes es un problema de organizar el equipo de trabajo y no de POO o de MVC. No se crea POO o MVC para facilitar la integración de un equipo de trabajo, estás mezclando cosas que no tienen nada que ver entre ellas.
Anexo: he trabajado con equipos de desarrollo de "más de 1 persona" y se usa MVC, Zend, PHP, POO y diseñadores sin problemas (y no desechamos nada por no tener plantillas para los diseñadores puedan cambiar todo "en caliente").
Cita: Qué es mejor o peor no lo definen los creadores de php, tampoco gurús en diseño de sitios interactivos y tampoco lo hará ningún usuario de acá (incluyéndome), ni tampoco tú, lo que decidirá qué viene mejor es tu proyecto y sus necesidades, el tipo de información que maneja, dónde la presenta, qué otras cosas se hace con la información, dónde la guarda, quiénes tienen acceso a esa información....
Opino un poco distinto, tienes que aprender de quienes saben y de sus experiencias, finalmente optar por un camino con fundamento y adecuado al proyecto, pero no puedes inventar la rueda (otra vez).
