de php, a php objetos

[adg]

hola..
tengo un sitio hecho con php y lo quiero pasar a php orientado a objetos..
ya se programar en objetos con otros lenguajes como pj java y no tengo problemas para armar las clases correspondientes al modelo de dominio.

pero... me complican un poco algunas cuestiones que tienen que ver con armar las clases que van a ser las vistas del sitio...por ejemplo: como armaria una clase para el login y su comprobacion??

que es lo que tengo que tener en cuenta para armar clases que van a ser las vistas del sitio, en donde voy a tener lo controles(textos, tablas, forms, etc)??

espero haber explicado bien..

por favor.. solamente algun ejemplo de una clase que muestre controles en pantalla....gracias

[Synkronice]

Te sugiero usar el patron de diseño MVC (Modelo Vista Controlador).

Si tienes ganas y tiempo

implementatelo tu

En caso contrario

usa algunos de los FrameWorks existentes

Por ejemplo:

Symfony
Zend FrameWork
CakePhp
etc...

Saludos!

[adg]

sisi...lo estoy haciendo con MVC y clases...pero como armo las clases que muestran los controles en la pantalla y que recien datos de otro formulario??

[yoguuu]

Yo te aconsejaría ke no te me oceques intentando crear algo que no vas a ser capaz de crear... y usaría Zend Framework, ke para algo es el oficial de php. :P Y ya está hecho.

[isra00]

Tienes que ir un poco más allá. Si quieres orientar a ojetos tu aplicación, seguramente no debas usar CakePHP, por ejemplo. Esto es debido a que, aunque a nivel de código sí uses POO (cada vista, modelo y controlador es una clase), en realidad no estás orientando tu aplicación a objetos.

Te comento una aproximación que sigo en mis proyectos últimamente. Como en cualquier software, debes decidir y definir las capas en que se compondrá tu sitioi web. El primer paso es definir con qué objetos vas a trabajar. Por ejemplo, si vas a hacer un catálogo de coches de segunda mano, seguramente tus objetos de negocio son coche, persona (para compradores/vendedores), concesionario, etc. Estos son los objetos que principalmente vas a tratar, y que seguramente puedas definir fácilmente accediendo a tu base de datos y observando su estructura. Con esto ya tenemos la capa de objetos de negocio

Después de definir estas clases debes crear una capa para el acceso a datos. Las clases y métodos que crees aquí accederán a la base de datos y trabajarán con los objetos de negocio, de tal modo que SÓLAMENTE EN ESTA CAPA se ejecuten consultas SQL. Por ejemplo, getCochesPorCuidad($nombreCiudad), editarOferta(Oferta $oferta). Estos métodos conectan BD con objetos, de forma transparente a las capas que hay por encima y por debajo. Esta metodología se llama DAO, Data Access Object (http://es.wikipedia.org/wiki/Data_Access_Object).

Después viene la interfaz. Aquí puedes usar un motor de plantillas (ayudan mucho, yo no sé qué haría sin ellos) como Smarty o PHPTAL (http://www.israelviana.es/blog/post.php?id=35) para generar HTML/CSS/JavaScript de forma más limpia. En esta capa definirás los módulos funcionales del sitio web, por ejemplo Inicio, Búsqueda, VerOferta o Login. Por ahora no entraré en detalles de cómo definirás esto, aunque lo más básico es hacer un script no orientado a objetos por cada módulo, como seguramente tendrá ahora. Lo bueno de PHP es que te permite combinar orientación a objetos y no-OO lo que permite entender bastante bien el funcionamiento del código.

Como podrás ver, esta metodología se parece bastante al MVC. Personalmente utilizo en mis aplicaciones 5 ó 6 capas, entre las que se encuentran éstas.

Para el tema de login, como para muchos otros, debes tener presente que Java se ejecuta sólo en el escritorio y los sitios web siguen modelos cliente-servidor, donde el cliente tiene HTML/CSS/JS y el servidor, PHP. Esto, unido a que HTTP no es un protocolo orientado a conexiones (como sí podría ser una aplicación de escritorio, aunque fuesen conexiones "virtuales"), impide trabajar con temas como Autenticación de forma similar. Te aconsejo que, para las sesiones, sigas usando el método que usabas hasta ahora. Repito, PHP tiene la ventaja (a veces desventaja) de poder mezclar OO y no-OO, de tal forma que puedes ir migrando gradualmente tu aplicación.

Espero que te haya ayudado a empezar a formarte una idea de cómo sería un sitio web OO. Huelga decir que es una de las muchas maneras que hay, ya que el término "aplicación con OO en PHP" puede dar lugar a muchas interpretaciones. Últimamente escribo bastante sobre el tema en mi blog (http://www.israelviana.es). Estoy preparando un post sobre cómo organizar los ficheros en una arquitectura de aplicación más o menos como te he comentado, y tener nuestro propio "framework" casero, para organizar la funcionalidad en módulos y vistas (http://www.israelviana.es/blog/post.php?id=30).

Es un mundo inmenso la orientación a objetos en aplicaciones web. Me alegro de que entres en él, si tienes cualquier duda puedes contactar conmigo a través del blog, aunque tampoco soy ningún experto

Saludos.

[CAT Shannon]

Iniciado por isra00

Si quieres orientar a ojetos tu aplicación, seguramente no debas usar CakePHP, por ejemplo. Esto es debido a que, aunque a nivel de código sí uses POO (cada vista, modelo y controlador es una clase), en realidad no estás orientando tu aplicación a objetos.

No entiendo muy bien a qué te refieres cuando dices que con CakePHP no usas realmente OOP. Si bien es cierto que CakePHP es poco estricto (permite atributos públicos y otras prácticas), al final, el nivel de OO lo defines tú en el uso que le des.

Por cierto, un pequeño apunte: Java si que se puede ejecutar en el servidor. Existen los servlets Java que te permiten usar Java como lenguaje de servidor.

Saludos...

[isra00]

Estimado Shannon, o me he expresado mal o no me has entendido... lo que quería decir es que usar una sintaxis o unas construcciones de lenguaje orientadas a objetos (como ya he dicho, las vistas, modelos y controladores se expresan como clases) no implica orientar tu aplicación hacia la POO en el sentido que yo entiendo orientar a POO. Pongo el ejemplo de Cake porque la comunicación entre las capas del software se produce con variables sencillas que corresponden a campos de una base de datos relacional. Este detalle para mí es importante (seguramente sea una tontería), pero si el programa no tiene objeto Coche y objeto Persona -por poner un ejemplo- no puedes decir con todo rigor que el software esté orientado a objetos. Repito, es mi opinión y probablemente esté equivocado.

Ah, y conozco Java sobre servidor, tengo experiencia con servlets y diversos frameworks. El ejemplo de Java era para diferenciar tecnologías de escritorio y tecnologías web (cliente-servidor).

[CAT Shannon]

No sé de dónde sacas que la comunicación entre capas de CakePHP se produce con variables sencillas que corresponden a campos de una base de datos relacional.
Te pondré un ejemplo rápido. En un controlador puedes hacer referencia a un modelo. Ahí hay una comunicación entre capas y en ambos casos son objetos.

No todo gira en torno a la bases de datos. Pongamos por ejemplo que en una vista puedes usar un Helper. Estás usando un objeto.
Y sin entrar ya en el tema de los Components y Behaviours, que es donde está gran parte de la fuerza de CakePHP. Y ahí si que tienes OOP.

Además, puedes usar tus propios objetos fuera del patrón MVC. Por ejemplo, yo tengo una clase para redimensionar imágenes y la uso como un objeto más.

El tema de CakePHP es que es de más alto nivel que Zend u otros frameworks, con lo que tienes que adaptarte a su forma de trabajar. En ese sentido sí que pierdes flexibilidad y autonomía, sin embargo, ganas en velocidad de desarrollo.

Como te dije, al final el nivel de OOP lo defines tú en el uso que le das. Evidentemente tienes que usar un mínimo por cómo funciona CakePHP, pero en el resto no hay límite.

[adg]

lo más básico es hacer un script no orientado a objetos por cada módulo, como seguramente tendrá ahora. Lo bueno de PHP es que te permite combinar orientación a objetos y no-OO lo que permite entender bastante bien el funcionamiento del código.

Te aconsejo que, para las sesiones, sigas usando el método que usabas hasta ahora. Repito, PHP tiene la ventaja (a veces desventaja) de poder mezclar OO y no-OO, de tal forma que puedes ir migrando gradualmente tu aplicación.

estas son las respuestas que necesitaba... gracias por tus aportes "isra00" y las demas personas...pensaba que nadie iba a responder jajaj..

isra00..despues con mas tiempo me voy a fijar en tu blog...seguramente despues te pregunte algunas cosas mas sobre este tema..
y tengo algunas preguntas mas que seguramente despues les haga sobre MVC..
chauu graacias

[isra00]

Un placer ayudar

CAT Shannon, tienes toda la razón del mundo y seguramente me haya pasado al generalizar un caso concreto en Cake hacia toda la estructura y filosofía de funcionamiento de ese gran framework. A lo que me refería era a cosas como el método findAll(), que devuelve un array con los campos de la base de datos. El modelo que yo suelo seguir persigue una abstracción de las estructuras de persistencia, en este caso campos de una tabla relacional.

Gracias por tus comentarios. Un saludo.

[CAT Shannon]

isra00, sí, tienes razón en cuanto al método findAll. Hay gente que prefiere que se devuelvan objetos, y de hecho no sería nada difícil implementarlo para CakePHP. Personalmente lo prefiero como está pero esto ya es una cuestión de gustos.

Seguramente si necesitas trabajar más con los datos que recibes, quizá sí que te convenga que sea un objeto. El problema es que entonces perderías esa velocidad de desarrollo que te da CakePHP porque tendrías que definir para cada atributo sus get y set en el modelo. Quizá podrías solventarlo con __get y __set, pero no me parece muy elegante porque o te cargas el encapsulamiento o tienes que definir qué atributos se devuelven con este método.
Total, que CakePHP es lo que es: un framework de más alto nivel con su propia filosofía de trabajo.

Un saludo.

[isra00]

Efectivamente, hace poco me comentaba un compañero su opinión. Él programa en C# y es fanático de la comunicación entre capas basada en variables, ya que de este modo se programa hacia la interfaz y se mantiene una unión mucho más natural con la base de datos. Es cosa de personalidades: pragmático o idealista

[adg]

tengo una duda con el patron MVC el modelo de tres capas(modelo, vista, controladora):

Segun lo que me comentó israOO:
_Por un lado tengo las clases que forman parte del modelo de dominio (entidades logicas),
_por el otro lado como vos decías israOO tengo la capa de acceso a datos donde van las instruciones SQL que interactúan con la base de datos,
_ y luego tengo la vista..

estas 3 capas esta claro....pero donde va la controladora?? entonces teniendo modelo-vista-controladora-acceso a datos sería un modelo de 4 capas o continúa siendo de 3 capas??

[jahepi]

Iniciado por adg

tengo una duda con el patron MVC el modelo de tres capas(modelo, vista, controladora):

Segun lo que me comentó israOO:
_Por un lado tengo las clases que forman parte del modelo de dominio (entidades logicas),
_por el otro lado como vos decías israOO tengo la capa de acceso a datos donde van las instruciones SQL que interactúan con la base de datos,
_ y luego tengo la vista..

estas 3 capas esta claro....pero donde va la controladora?? entonces teniendo modelo-vista-controladora-acceso a datos sería un modelo de 4 capas o continúa siendo de 3 capas??

Hola adg !

Estás confundiendo lo que es diseño en 3 capas con MVC que es un patrón de diseño.

Encontré un artículo interesante que habla sobre el tema:
Diseño en 3 capas != MVC

En el blog de Enrique hay un artículo sobre el diseño en 3 capas:
Diseño en 3 capas

Artículos sobre el patrón de diseño MVC:
http://es.wikipedia.org/wiki/Modelo_Vista_Controlador
http://www.proactiva-calidad.com/java/patrones/mvc.html

Espero que esas ligas te sean ayuda.

Un saludote !

[adg]

bueno voy a ver como me va...muy buenos los articulos!! te cuento que el dueño de este blog "Diseño en 3 capas != MVC" es un profesor mio de la facu, es muy buen profe!

gracias..