Cita: Para ello he leido mucho acerca de POO y MVC, me he pasado casi todo el día de hoy leyendo el Blog de Enriqueplace y de pronto siento que mi vision se abre totalmente; y con ello obviamente vienen los cuestionamientos y las dudas.
Bueno, gracias por los comentarios, me reconforta -sin intención de tener la verdad absoluta- que sirva por lo menos para cuestionarte las cosas como las haces hoy día e investigar buscando nuevas formas
Cita: Mas o menos sobre esta tendencia (creo), yo soy (o era?) de la idea de que a menor cantidad de ficheros es mejor... pero ahora que me meto al mundo del MVC obsevro una tendencia a generar mas ficheros .php de los que estaba acostumbrado.
Mmm... estás mezclando cosas, saltas de "cantidad de líneas de código" a "cantidad de ficheros" como si fueran iguales. El punto no es ese, todo depende de la organización que quieras llevar, la estrategia de tu diseño y el tamaño de tu sistema.
El punto es, no entrar en "excesos de abstracciones" (muchas clases, muchos archivos, etc) cuando el problema es mucho más simple. Si tienes que hacer un simple ABM, crear 25 clases y 50 archivos posiblemente sea exagerado (a menos que el contexto sea crear el super-abm que luego podrá crecer en 50 ABMs similares).
Cita: Si antes yo usaba un archivo para clientes (clients.php), ahora deberia usar 3, uno para el modelo, otro para el controlador y otro para la vista... Es esta lógica correcta?
Depende, nuevamente, del tamaño del sistema. Como criterio deberíamos manejar que *siempre* algo que llamemos "sistema" (no páginas dinámicas simples) debería tener por lo menos 3 capas: presentación, dominio, y persistencia, capas bien separadas por su responsabilidad.
MVC no es directamente "3 capas", es algo similar pero distinto, si quieres, le podemos decir que es "una arquitectura de 3 capas más especializada".
Resumiendo: no se mide en cantidad de archivos, mide en "cantidad de abstracciones" (aunque finalmente si trabajas en POO cada clase deberá ser un archivo), y si haces un sistema, divídelo en 3 capas ya desde el inicio, y si consideras que el tipo de proyecto es más complejo y cabe su aplicación, evalúa un sistema MVC con algún framework (como Zend).
Fundamental -en mi opinión- no reinventas la rueda en ningún caso, no hagas un "nuevo" sistema de persistencia o MVC, tu problema es hacer sistemas y cobrarlos, no crear ruedas semi-redondas que nadie entenderá ni pagará.
Espero se entienda la lectura "entre líneas"