Programacion a 3 capas PHP

[enriqueplace]

(¿Bueno, Casuis, GatorV, etc, donde andan? )

Iniciado por DarioDario

Hablando desde la completa ignorancia tengo algunas dudas sobre lo que dices enriqueplace, "namespace" se lo llama a lo siguiente?:

Código PHP:

  // Invoco ambos paquetes completos 
import dominio; 
import presentacion;  
 
// Invoco un elemento a partir del paquete 
dominio.DominioFachada::traerUsuarios();  
   

(Me refiero al detalle de dominio.DominioFachada)

Salvado las diferencias, tanto el "package" de Java como el "namespace" de .Net harían cosas similares, en el concepto, al crear "unidades contenedoras" de otras unidades contenedoras o elementos (un "paquete" puede contener clases y otros "paquetes", etc).

El tema es, supuestamente (tengo que repasarlo), el concepto de "namespace" de .Net sería conceptualmente más amplio que el "package" de Java.

Pero concretamente con PHP5, fue el nombre que eligieron, y como no lo terminaron de implementar y no tengo documentación al alcance, no sé si se parece más a Java o a .Net. Pero, básicamente, con ambas puedes representar el clásico "paquete" de un diagrama UML.

Algo que, lamentablemente, no existe hasta la fecha para PHP, por lo cual no nos podemos llamar "como lenguaje" algo 100% Orientado a Objetos. Si existen, por lo que tengo entendido (y algún colega con más conocimientos en el tema puede corregirme) frameworks que implementan esta funcionalidad.

Serían sinónimos todos los términos empleados: "paquete", "namespace", "package" o "capa" (esto último se representa con un "paquete").

Iniciado por DarioDario

Por lo poco que aprendi de Python, esto se aplica... pero sigo sin entender del todo el tema.

Desconozco Python como para decirte con exactitud, pero si tiene una sintaxis para definir alguna forma de "agrupación", la idea es la misma.

Nota: UML no está atado a lenguajes específicos, pero los lenguajes deben ser OO para poder cumplir cabalmente con los diagramas. Si te muestran un diseño hecho en 3 capas, te mostrarán un dibujo de tres paquetes con flechas de dependencias entre ellos, por lo cual deberás implementar de alguna forma esta "separación conceptual" (y la forma más simple es hacerla "a lo Java") .

Iniciado por DarioDario

Con lo poco que entiendo sobre este tema la separación de capas es más logica que fisica, pero haces uso de un ejemplo que muestra una separación "fisica". También veo que en lo que escribes das a entender (o entiendo yo) que el modelo MVC no es programar en capas, entonces, que lo es?

Vamos por partes, no quiero confundir con lo que digo. La separación es lógica, no necesariamente física; pero partí de lo que sucede concretamente en Java cuando creas un paquete. No tengo idea si en .Net sucede lo mismo a nivel del disco, pero no es lo importante.

Pero, gracias a que Java lo hace así, en mi humilde búsqueda del conocimiento en el mundo de PHP, trato de aprender de los ejemplos y las buenas experiencias de mis "vecinos", por consiguiente, imito el mismo comportamiento que Java.

Sobre el MVC: digo que sería "casi lo mismo", si fuera lo mismo, un "sistema en 3 capas" podría ser sinónimo del patrón MVC y viceversa. Pero yo puedo seguir desarrollando y mejorando el ejemplo didáctico que expliqué, pero así como está no es el patrón de diseño MVC, aunque ambos hagan separación de responsabilidades en "capas" distintas.

Mirá lo que dice wikipedia del MVC:

"Es común pensar que una aplicación tiene tres capas principales: presentación (IU), dominio, y acceso a datos. En MVC, la capa de presentación está partida en controlador y vista. La principal separación es entre presentación y dominio; la separación entre V/C es menos clara."

¿Se entiende lo que quise decir?

Iniciado por DarioDario

Ahora pensando un poco más, puede ser que estas hablando sobre un problema que te encontras cuando programas en capas y hablas sobre su posible solución a falta de "namespace"?.

Si, eso es lo que trato de comentar, el "problema a bajo nivel". El hecho que el lenguaje no te "encapsule" esa problemática hace que se derive al desarrollador, convirtiéndose de alguna forma en "un problema de manejo de directorios e invocaciones desde distintas ubicaciones".

Intenta implementar el mismo comportamiento y verás lo que te digo.