Programacion a 3 capas PHP

[Fher]

hola a todos!! regreso a porgramar php y claro he aprendido un poco mas aprendiendo a programar objetos ya que estuve programando en aspx y estuve ahi haciendo algunas aplicaciones sencillas a 3 capas sobre .net y me parecio muy buena la forma en que se programa

ahora la ultima vez que programe php fue programacion estructurada ustedes saben todo en una sola misma pagina pero ahora mi programacion se ha pulido un poco mas y les pregunto si alguien esta programando a 3 capas en php y como lo hace ?? ya que voy a hacer mi sitio web con un modelo de negocio con la capa de presentacion, de negocios y acceso de datos.. alguien tiene por ahi ejemplos de codigo, o que nombre recibe programar de esta forma en php ??

hagamos un ejemplo sencillo para ver como funciona programar en 3 capas en php. supongamos que quiero hacer una consulta a mi base de datos de mi pagina y para esto..

tengo un mi pagina donde pongo el objeto de la capa de presentacion y asi accedo a mis datos.. que llamaremos pagina 1

en la pagina 2
la capa que sigue tengo mi objeto de negocios que accede a mi capa de acceso de datos

en mi pagina 3
donde tengo mis objetos que acceden a mis conexion de base de datos y la tabla por un select..

alguien conoce de esto en php y como hacerlo para divir mi codigo por 3 capas ?? gracias

[enriqueplace]

Bue.... es un tema largo y árido... y espero que no polémico (hay un libro por cada maestro )

Ya he tratado el tema cuando en algún momento pregunté que pasaba con los "namespace" que estaban en las betas y hasta en las presentaciones de lo que iba a venir con PHP5, pero que finalmente no aparecieron.

Todo se resume que al carecer de una sintaxis como "namespace" (idem a .Net) o "package" (idem a Java) no se puede traducir directamente el correspondiente elemento UML (el "paquete") de forma directa en PHP5.

Visto de otra forma, ahora, para implementar algo del tipo "n capas", todo se convierte en un problema de manejo de subdirectorios y "llamadas relativas", buscando evitar llamadas del tipo "../" (que son dependientes de donde se están invocando y pueden devolver cualquier cosa).

Lo que internamente sucede, por ejemplo en Java, cuando creas un paquete se crea internamente una carpeta/subdirectorio. Por lo pronto, esto es igual si lo quieres hacer en PHP.

• dominio
• persistencia
• presentacion

El punto es, luego, como resolver las invocaciones que puedes hacer dentro de cada "paquete" y no tener problemas de hacerlo desde cualquier ubicación.

Parches posibles: crear un archivo de configuración en la raíz del proyecto, y por cada paquete, un archivo local que apunte al de la raíz, y cada clase del paquete usa su archivo local. Puedes intentar definir constantes que apuntes a cada capa, para luego invocarlas de cualquier lado:

Código PHP:

  // Archivo de configuración: 3 capas 
define('DOM', APP."/dominio"); 
define('PRE', APP."/presentacion"); 
define('PER', APP."/persistencia");  
   

Como lo invocaría:

Código PHP:

  require_once 'configuracion.php'; 
 
require_once(DOM."/DominioFachada.class.php"); 
require_once(PRE."/PresentacionFachada.class.php"); 
 
PresentacionFachada::listarUsuarios(DominioFachada::traerUsuarios());  
   

Lo malo, al no tener algo del tipo "package" o "namespace", no puedes ni invocar enteramente un "paquete", ni hacer referencias puntuales a un elemento nombrando al paquete como partida, ejemplo:

Código PHP:

  // Invoco ambos paquetes completos 
import dominio; 
import presentacion;  
   

Código PHP:

  // Invoco un elemento a partir del paquete 
 
dominio.DominioFachada::traerUsuarios();  
   

Lo más prolijo, pasar a un modelo modular, donde al entrar siempre por el mismo lugar pueden definir el archivo de configuración en un solo lado y no tener que obligar que cada parte invoque al suyo.

Le evolución del modelo "web modular" sería pasar a un patrón MVC, que a los efectos sería casi lo mismo que separarlo en 3 capas con responsabilidades distintas.

Resumiendo: no es tan trivial implementar algo de esto (no lo hubieran sacado entonces de la beta de PHP5), pero bien podrían incluirlo en PHP6 (pero no va a suceder), lo cual en mi humilde opinión es grave y problemático (algo que el lenguaje debería resolver y no el desarrollador).

Es un resumen muy rápido, pero tengo que escribir un artículo sobre esto

PD: ahora... ¡lluevan las piedras!

[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)

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

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?

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"?.

Saludos.

[GatorV]

namespace es un espacio donde agrupas clases que se relacionan por decir controles de un formulario van en el namespace de forms.

Los desarrolladores de PHP tienden a agrupar clases en directorios comunes, (ve por decir el ZendFramework).

Java y .NET por decir usan esos namespaces pero el compilador puede actuar de forma que si tu pones:

Código:

text1 = new forms.controlTextbox();

Analiza que controlTextbox es una clase del paquete o namespace forms, e importa ese paquete y crea la clase.

PHP por su lado no hace estos analizis dinamicos y requiere que tu incluyas la clase antes:

Código PHP:

  include( "forms/contolTextBox.php" );
$text1 = new controlTextBox();  
   

Los namespaces es algo que se hablo en PHP6 pero lo desarrolladores no estan muy seguros de incluirlo.

MVC no esta atado a una capa fisica o logica, es mas bien un paradigma de programacion en el que separas la capa de trabajo de la vista por lo que es mas sencillo expandir y controlar tu programa al tenerlo en "modulos" que hacen cierto trabajo y en vistas (ya sea HTML, PDF, Texto, etc.)

Por decir un mismo controlador con un modelo puede sacar el contenido en varios formatos, y en la programacion "estructurada" requeriria reprogramar cada script, aqui lo unico que haces es actualizar el controlador para que use una vista diferente.

Espero con esto te quede un poco mas claro,

[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.

[GatorV]

Y solo para complementar, es posible hacerlo en PHP, depende de tu forma de programacion puedes implementar los programas/scripts en sus ambientes contenidos y hacer algo como:

Código PHP:

  import( "com.miempresa.modelos.usuarios" );

$usuarios = new usuarios();  
   

Esto hace que PHP busque en com/miempresa/modelos/usuarios.php

Es muy factible hacer alog asi en PHP, te lo digo porque mi Framework lo hace, y encuentro que es mas facil separar la logica de las clases que necesito por codigo.

Espero que no sea mucha información para digerir jaja, saludos!.

[enriqueplace]

Bueno, aprovechemos la oportunidad, a mi me interesa saber como se puede implementar una invocación de ese estilo

PD: vos sabés que yo soy una esponja... no Bob, pero soy una

[GatorV]

Bueno para explicar como implementar algo asi es como crear un microframework, con lo basico:

- Archivo de Configuracion
- Archivo de Booteo (o Archivo de inicializacion)
- Directorios de Busqueda Predefinidos
- Directorios de Presentacion Predefinidos
- Script de Router para saber que clase cargar dependiendo del URL (patron MVC)

Lo que haces es que tu archivo de Booteo, cada que recibe un request, carga la configuracion, activa el router/dispatcher, lee el URL y activa el controlador y accion correspondientes.

Ya con esto tu controlador ya tiene a su disposicion el archivo de configuracion disponible, asi como en que directorio esta y es posible "importar" ahora si los paquetes que ese controlador va a trabajar.

Un layout posible de directorios seria:

Código:

/www/aplicacion/
      ..../index.php // Archivo de Booteo
      ..../configuracion/configuracion.php  // Archivo de Configuracion
      ..../controladores/ // Directorio de los controladores
      ..../vistas/ // Directorio con las vistas
      ..../aplicacion/ // Directorio con la aplicacion es aqui donde esta el "core"
      ..../aplicacion/com/empresa/ // Directorio base cuando se importa com.empresa.algo
      ..../aplicacion/com/empresa/subdirectorio/ // Subdirectorio para mostrar como se puede leer de cualquier subdirectorio

Una vez definido creamos nuestra funcion de import:

Código PHP:

  import( $class_path ) {
    $class_path = str_replace( ".", DIRECTORY_SEPARATOR, $class_path );
    $class_path = BASE_DIR . "/aplicacion/" . $class_path; // BASE_DIR puede estar definida en la configuracion.
    require( $class_path ".php" );
}  
   

Espero que sea claro jeje

[Fher]

creo que se desviaron del tema y realmente no me dieron un ejemplo de lo que estoy pidiendo algo del cual yo me pueda guiar.,. disculpen por ser limonesnero y con garrote

[enriqueplace]

Pero perdón, fuera de lo desubicado de GatorV (obvio, hasta a mi me supera su código ), yo ya te di una explicación racional del problema y un indicio por donde se puede trabajar desde PHP.

Más directo en mis argumentaciones no pude ser.

[DarioDario]

Muchas gracias GatorV y enriqueplace por sus respuestas, ahora el paronama me queda más claro. Yo tenía/tengo una idea sobre la programación en capas pero al parecer mucha información junta en un solo post fue suficiente para hacer que dude sobre todo . Tengo ganas hace tiempo de empezar a aplicar esto, pero no tengo tiempo y lamentablemente en el trabajo no me dejan aplicar estas cosas (si si, como lo leen, no quieren que aplique estos conceptos y directamente que evite lo mas posible los objetos, la razón? no sé, a mi también me gustaría saberlo).

Iniciado por Fher

creo que se desviaron del tema y realmente no me dieron un ejemplo de lo que estoy pidiendo algo del cual yo me pueda guiar.,. disculpen por ser limonesnero y con garrote

Creo que hay bastante información con las respuestas que se dieron, en todo caso si no te alcanza utiliza el buscador, se ha hablado muchaaaaaas veces


Espero no hacer una burrada, pero que les parece ésta modificación al código que ha puesto el compañero GatorV?

Código PHP:

  import( $class_path )
{
    $class_path = explode(".",$class_path);
    $objeto = array_pop($class_path);
    $class_path = implode(".",$class_path);


    $class_path = str_replace( ".", DIRECTORY_SEPARATOR, $class_path );
    $classe = explode
    $class_path = BASE_DIR . "/aplicacion/" . $class_path; // BASE_DIR puede estar definida en la configuracion.

    // Se hace un require_once por si se llaman varias clases de un solo archivo, así que tire un error al llamar dos veces el mismo archivo
    require_once( $class_path.".php" );

    return new $objeto();
}  
   

De esa forma no solo se incluye el archivo sino que tambien te crea un instancia de una clase, entonces se llama así:

Código PHP:

  $instancia_bebe = import("clasess.mama.bebe");
// esto buscara ./clasess/mama.php y creara una instancia de la clase bebe  
   

Espero que se entienda el código y sirva de algo.

Ahora cambiando un poco el tema, sabén de alguna aplicación open source que este programada en capas? Es para estudiar su código ya que no tengo tiempo de practicar y golpearme la cabeza

Saludos.

[B**]

Que buen tema !(mis respetos Gatorv y enriqueplace)..........yo desconocia el paradigma 3 capas, aunque en algun momento lo escuche en clase, pero no profundizaron..

[zen719]

gracias enriqueplace y gatorv por tomarse el tiempo para explicar (tamb esperaba los comentarios de Casuis) si que se aprende de uds 3.
me queda mas claro a ti tambien muchas cosas =)

[GatorV]

Que tal Dario, la idea de hacerlo de la forma que lo habia propuesto es porque en mi framework me encontre con el problema cuando guardas objetos en las sesiones, tienes que incluir la definicion de la clase antes de iniciar la sesion.

Mi Framework primero lee los imports de tu clase, incluye esas clases, luego crea la sesion y despues crea la instancia de la clase.

Asi te evitas problemas al usar sesiones y objetos, aparte de que se parece mucho mas a Java:

Código PHP:

  import( "com.empresa.seguridad.usuarios" );
import( "com.empresa.usuario" );
import( "com.empresa.proveedores" );

class altasController extends GeckoController {
       public $productos = array();
       private $currentUser = null;

       public function __construct() {
             $this->currentUser = $this->getStorage()->get( 'usuarioActual' );
             if( !isset( $this->currentUser ) ) {
                   $this->redirect( "/login/" );
             }

             if( $this->curentUser->getSecurityLevel() != 1 ) {
                   $this->saveMsg( "No estas autorizado para ver esta pagina" );
                   $this->redirect( "/" );
             }
       }

       public function index($request) {
             $proveedores = new proveedores();
             
             $this->productos = $proveedores->findAllProductos();
       }
}  
   

[enriqueplace]

Bueno, más o menos, pero he quedado "excitado"

Todavía no logro ver completamente como funciona (tal vez por la conjuntivitis que me aqueja en este momento y que estoy leyendo mientras mis ojos sangran ) ... pero me parece que me voy a tener que sentar a estudiar tu framework

[enriqueplace]

Iniciado por DarioDario

Muchas gracias GatorV y enriqueplace por sus respuestas, ahora el paronama me queda más claro. Yo tenía/tengo una idea sobre la programación en capas pero al parecer mucha información junta en un solo post fue suficiente para hacer que dude sobre todo . Tengo ganas hace tiempo de empezar a aplicar esto, pero no tengo tiempo y lamentablemente en el trabajo no me dejan aplicar estas cosas (si si, como lo leen, no quieren que aplique estos conceptos y directamente que evite lo mas posible los objetos, la razón? no sé, a mi también me gustaría saberlo).

Dos cosas, deben conocer el UML... toda documentación de diseño se hace así, y en mi humilde opinión, aprender y/o trabajar orientado a objetos sin este conocimiento es un completo disparate.

Lo segundo, si tienen "miedo" es por ignorancia... le temen a lo desconocido.

Iniciado por DarioDario

De esa forma no solo se incluye el archivo sino que tambien te crea un instancia de una clase, entonces se llama así:

Ojo, no necesariamente debes necesitar una instancia del objeto, muchas veces trabajas directamente con la clases, por lo cual tu cambio condicionaría la forma de trabajo.

Iniciado por DarioDario

Ahora cambiando un poco el tema, sabén de alguna aplicación open source que este programada en capas? Es para estudiar su código ya que no tengo tiempo de practicar y golpearme la cabeza

Mira, cualquier proyecto de desarrollo de "mediano para arriba", que además tenga varias personas o equipos trabajando, no podrá ni arrancar si no lo dividen en por lo menos 3 capas.

Sobre el ejemplo, como estoy dictando un curso sobre el tema, estoy viendo si dejo disponible el material que he armado y los ejemplos. A mis alumnos les he entregado un "proyecto base" -muy elemental- para que pueden a partir de él llenar "los espacios en blanco" y concluir la aplicación (deberán obviamente seguir la estructura de trabajo o todo se vendrá abajo).

Lo primero que se nota en un sistema en capas es que si el desarrollo es pequeño tienes una sobrecarga importante al tener que estar pasando entre "intermediarios" información de capa en capa, para luego volver a la capa de origen.

Pero cuando te acostumbras, te das cuenta que es la única forma de trabajo, y que puedes organizar luego equipos de desarrollo que trabajen de forma independiente sobre cada capa sin ningún problema.

¿O tu porqué piensas que dividieron el modelo OSI y el TCP/IP en tantas capas? Cada capa se comunica con la siguiente, pasando los datos que recibe, y solo se procesan cuando llegan a la capa responsable de esa tarea.

Es el mismo concepto.

[B**]

GatorV...esta linea que es lo que hace?
$this->getStorage()->get( 'usuarioActual' )...

[GatorV]

Devuelve un objeto del registro persistente (para poder pasar objetos entre pagina y pagina de una manera mas sencilla, su motor principal son las sesiones, pero se puede cambiar el "engine" para usar un archivo de texto, o una base de datos)

@Enriqueplace

Como! jaja yo pensaba que ya te habias super estudiado mi framework , realmente a mi me gusta la forma de aislar todo y hacer clases y sus templates (o vistas) correspondientes.

[enriqueplace]

Lo miré por arriba, no tengo excusa ni perdón, pero ni bien me libere de compromisos, me meto de lleno a desarmarlo... por lo cual nos vas a tener que ayudar a armar otra vez

PD: ya está pronto el blog del mismo? (cuando seas famoso, acordate de los amigos )

[GatorV]

No he tenido tiempo de armarlo, jaja estoy armando un wiki con la documentación, y después de esto ya hare el blog con ejemplos de uso.

Por cierto es muy benefico encontrar hosts con PHP5.1 para que puedas no nadamas poner documentacion sino ejemplos reales.

[jahepi]

Iniciado por GatorV

No he tenido tiempo de armarlo, jaja estoy armando un wiki con la documentación, y después de esto ya hare el blog con ejemplos de uso.

Por cierto es muy benefico encontrar hosts con PHP5.1 para que puedas no nadamas poner documentacion sino ejemplos reales.

Hola GatorV!!!!

¡Que bueno que sigas avanzando en la documentación de tu framework!, como muchos aquí, me muero de ganas por implementarlo en mis proyectos, tiene "GRANDES" cosas y su facilidad de uso lo hace muy versátil.

¡Mis más sinceras felicitaciones!.

Un saludo y suerte!

[la novata]

hola, ley su platica sobre el MVC, pero no me quedo muy claro. lo que pasa es que esto es nuevo para mi y se me ase un poco dificil de captar.

Si pudieran explicar de una manera mas sencilla el MVC se los agradeceria.

Por mi parte les digo que no entiendo muy bien esa separacion en capas, y como comunico una con la otra.

Supongamos que voy a desarrollar un sistema de control de estudios de una universidad x.

para el cual creare clases tales como: estudiante, profesor, carrera, materia....
son estas mis clases del negocio?

y en la capa de datos que debo tener?

lo unico que tengo claro es que las vistas son los formularios html?

si para cada clase yo creo un archivo disferente como comunico estos archivos.

ej:profesor->materia, o estudiante->carrera

[Fher]

Código:

 	hola, ley su platica sobre el MVC, pero no me quedo muy claro. lo que pasa es que esto es nuevo para mi y se me ase un poco dificil de captar.

digamos que me he alejado mucho en php pero como programaba en .net te explico como lo hacia y con un poco de imaginacion supongo que lo haces en php


mira el chiste de separar el codigo a 3 capas es un modelo de negocios basado en crear una capa de presentacion o de interfaces, esta sera el diseño html, el mostrar los datos por un objeto, por un xml etc, la que le sigue es la capa de negocios que es la que se encarga de darle toda la logica y los procesos aritmeticos, operaciones de validacion, que si tienes que enviar un email, alguna suma, resta, etc y la ultima capa es la de acceso de datos que es la que manipula la conexion de la o las bases de datos a ocupar, las consultas sql etc..

supongamos haces un programa para sumar 2 numeros y guardar el resultado en base de datos... si el modelo es a 3 capas te quedaria lo siguiente..

en tu archivo_de_presentacion.php tendrias que incluir el archivo donde le envias los parametros a la capa de negocios y en la capa de negocios hacer la suma porque la capa de presentacion es tu capa tonta y solo te sirve para mostrar o enviarle datos a la capa de negocios y por ultimo de tu capa de negocios a tu capa de acceso de datos para hacer el sql que te guarda ese resultado

quedaria asi de archivo_de_presentacion.php ----->> archivo_de_negocios.php-----> arhivo_de_acceso_de_datos.php. claro enviadole parametos a tus metodos y funciones de la capa que quesigue

ahora segun este modelo de arquitectura nunca debes de comunicar tu capa de presentacion con la de acceso de datos porque asi el paradigma estaria corrumpiendose aunque hay formas de hacerlo pero si aun en .net no he investigado menos en php y la razon de separar por capas es para que tu codigo se vuelva independiente, manejable y la gente que programe solo se enfoque a la capa que tenga que programar y asi delagamos responsabilidades porque cada quien a lo suyo, ademas porque es mas pro y habla de una buena arquitecto de sistemas..

bueno eso es lo que yo se, en .net pega de maravilla al igual que en JAVA pero por motivos de economicos estoy programando en php pero yo se que en un futuro php dara la batalla final a estos lenguajes y asi todos aprendamos mejor a diseñar apliacaciones

[Casuis]

Buenass el tema de los package o de los imports la verdad es que cuando se trata de php5 no le doy importancia y/o no es realmente necesario. <-- Y cuidado se lo que me digo (los programadores profesionales saben a lo que me refiero ;) )


Aunque a veces puede llegar a resultar útil cuando tienes un servidor que compartes aplicaciones o codigo aunque sigo sin verle utilidad.... aún así yo tenía un código que trabajaba con package si os sirve de algo os pongo un ejemplo de proyecto:

en nuestro directorio raiz crearemos el projecto(lo llamaremos package para ser originales ^^):

/opt/lampp/htdocs/package <-- linux (xampp)
c:\xampp\htdocs\package <-- windows (xampp)

estructura del proyecto:

Código:

package
  | - index.php
  | - package.php
  | + com
     | + programs
        | + saludo
           | - Contienente.php
           | - Mundo.php
           | - Pais.php

Bien una vez creada la estructura ponemos algo de codigo en nuestro ejemplo:
Bien esta sera nuestra aplicación (com/programs/saludo):

Continente.php

Código PHP:

  class Continente{
    
    public function getSaludo(){
        return "Hola desde Europa";
    }
    
}  
   

Mundo.php

Código PHP:

  class Mundo{

    public function getSaludo(){
        return "Hola Mundo!!";
    }
}  
   

Código PHP:

  class Pais{
    
    public function getSaludo(){
        return "Hola desde Catalunya";
    }
}  
   

Ahora en el directorio raiz crearemos el fichero package.php

Código PHP:

  <?php


class PackageException extends Exception { }




function import($class, $dirs = null)
{
    $path = str_replace('.', DIRECTORY_SEPARATOR, $class);
    $pathArray = split('\.',$class);

    if(count($pathArray)<=1)
        throw new PackageException("Error en la inclusion\"$path\"");
    if(end($pathArray) == "*")
    {
        array_pop($pathArray);
        $path = implode(DIRECTORY_SEPARATOR,$pathArray);
        $fullPath  = dirname(__FILE__).DIRECTORY_SEPARATOR.$path;
        $dirObj = new DirectoryIterator($fullPath);

        foreach ($dirObj as $nombrefichero){
            if(is_file($fullPath.DIRECTORY_SEPARATOR.$nombrefichero))
            {
                require_once($fullPath.DIRECTORY_SEPARATOR.$nombrefichero);
            }
        }

    }else{
        if (class_exists($class, false)) {
            return;
        }

        if ($dirs === null && $path != $class) {
            $dirs = dirname($path);
            $file = basename($path) . '.php';
        } else {
            $file = $class . '.php';
        }


        if (!class_exists($class, false)) {
            throw new PackageException("El fichero \"$file\" ha sido cargado "
            . "pero la  clase \"$class\" no ha sido encontrada.");
        }
    }
}


?>   

y por último el fichero index.php

Código PHP:

  <?php

include("Package.php");

import("com.programs.Saludo.*");



$saludo = new Mundo();
echo $saludo->getSaludo()."<br />";

$saludo  = new Continente();
echo $saludo->getSaludo()."<br />";;

$saludo  = new Pais();
echo $saludo->getSaludo()."<br />";

?>   

La salida por pantalla seria:

Hola Mundo!!
Hola desde Europa
Hola desde Catalunya



También podriamos haber cargado las clases de una en una declarandolas explicitamente:

Código PHP:

  <?php

include("Package.php");

import("com.programs.Saludo.Mundo");

import("com.programs.Saludo.Continente");

import("com.programs.Saludo.Pais");



$saludo = new Mundo();
echo $saludo->getSaludo()."<br />";

$saludo  = new Continente();
echo $saludo->getSaludo()."<br />";;

$saludo  = new Pais();
echo $saludo->getSaludo()."<br />";

?>   

[enriqueplace]

Iniciado por Casuis

Buenass el tema de los package o de los imports la verdad es que cuando se trata de php5 no le doy importancia y/o no es realmente necesario. <-- Y cuidado se lo que me digo (los programadores profesionales saben a lo que me refiero ;) )

No debo ser profesional porque no entendí qué es lo que quieres decir en concreto.

Iniciado por Casuis

Aunque a veces puede llegar a resultar útil cuando tienes un servidor que compartes aplicaciones o codigo aunque sigo sin verle utilidad.... aún así yo tenía un código que trabajaba con package si os sirve de algo os pongo un ejemplo de proyecto:

Estimo que tal vez el razonamiento venga por el lado de que si hacemos sistemas pequeños, simples, no es necesario. Pero si intentamos hacer cosas más complejas, donde tal vez ya sea mejor usar arquitecturas Java o .Net, deberían sí ser de utilidad.

Si te explayas un poco tal vez pueda entenderte

[Casuis]

Bueno la verdad es que para explicarlo sería un poco largo para hacer un post y hoy no tengo muchas ganas la verdad....

Ejemplo práctico:

Tienes un framework donde todas las acciones van redirigidas al index.php

y una acción : imaginate http://miaplicacion/carrito/add/categoria/2/item/3

al llamar a esta acción se redirigirá hacia index.php

Aquí es donde el patrón Router destripa la acción

Controller: carrito -> CarritoController
Action : add -> AddAction
params : categoria, item -> categoria = 2 item = 3

Router se comunica con Dispatcher que ejecuta el controlador adecuado con la acción adecuada y los parámetros.

Bien mmmmm nos da que pensar.... Uala todas las acciones que hagamos pasaran por Index.php y..... claro siempre se ejecutara index.php entonces...
Exacto podemos poner una funcion __autoload
( para más referencias mirar manual php5 )
y nos cargará todos los ficheros que necesitemos. La cuestión no es que es inútil utilizar imports.... sino que simplemente no tenemos que declarar ningun fichero se cargan automaticamente.... Fin de la cuestión.

[enriqueplace]

Iniciado por Casuis

Bueno la verdad es que para explicarlo sería un poco largo para hacer un post y hoy no tengo muchas ganas la verdad....

Bueno, suerte que yo hoy si tengo ganas de leerte

Iniciado por Casuis

Bien mmmmm nos da que pensar.... Uala todas las acciones que hagamos pasaran por Index.php y..... claro siempre se ejecutara index.php entonces... Exacto podemos poner una funcion __autoload ( para más referencias mirar manual php5 ) y nos cargará todos los ficheros que necesitemos. La cuestión no es que es inútil utilizar imports.... sino que simplemente no tenemos que declarar ningun fichero se cargan automaticamente.... Fin de la cuestión.

Mi opinión es que si nos quedamos en el "Mundo PHP" es lógico lo que comentas. Pero si nos vamos hacia un mundo más arquitectónico, buscando "elevar" el nivel de PHP, esto no necesariamente debe ser así.

Si yo hiciera el siguiente paralelismo: si estuviera en Java y usara el patrón MVC, ¿se justificaría entonces no usar el concepto de paquetes (por consiguiente, no usar imports)?

¿Verdad que no, que una cosa no anula a la otra?

El tema va más allá de que "todo entre por el index.php y que las clases se invoquen automáticamente". Si tu desarrollas un "sistema" como si fuera una "arquitectura", cuales son los componentes que se reutilizan entre sistemas?... la unidad mínima es un "paquete" y este se invoca, usando "imports"

No sé si entendió lo que quiero transmitir.

[anthemfor182]

Iniciado por enriqueplace

Bueno, suerte que yo hoy si tengo ganas de leerte

Mi opinión es que si nos quedamos en el "Mundo PHP" es lógico lo que comentas. Pero si nos vamos hacia un mundo más arquitectónico, buscando "elevar" el nivel de PHP, esto no necesariamente debe ser así.

Si yo hiciera el siguiente paralelismo: si estuviera en Java y usara el patrón MVC, ¿se justificaría entonces no usar el concepto de paquetes (por consiguiente, no usar imports)?

¿Verdad que no, que una cosa no anula a la otra?

El tema va más allá de que "todo entre por el index.php y que las clases se invoquen automáticamente". Si tu desarrollas un "sistema" como si fuera una "arquitectura", cuales son los componentes que se reutilizan entre sistemas?... la unidad mínima es un "paquete" y este se invoca, usando "imports"

No sé si entendió lo que quiero transmitir.

Estoy de acuerdo con Enrique la idea de desarrollar Frameworks, Simular Paquetes, Utilizar Patrones de Diseño y el utilizar POO, es intentar darle a PHP el toque arquitectonico que pueden tener otros lenguajes como Java.

PHP fue pensado desde una perspectiva de simplicidad inmediata pero para nadie es una mentira que al momento de desarrollar grandes proyectos las tareas de mantenimiento de estas aplicaciones se vuelven mas tediosas. Lo que buscamos mediante estas herramientas es tratar de favorecer la organización, evitar el codigo duplicado y en general facilitar el mantenimiento y el desarrollo de estas.

Espero que mi opinión sea de ayuda

Saludos

[enriqueplace]

Iniciado por anthemfor182

Estoy de acuerdo con Enrique la idea de desarrollar Frameworks, Simular Paquetes, Utilizar Patrones de Diseño y el utilizar POO, es intentar darle a PHP el toque arquitectonico que pueden tener otros lenguajes como Java.

Estimado, antes de dirigirme la palabra debes de haber sacado todas variables globales de tu framework... digo, por respeto a todos los que usamos POO.

Fuera de broma, sí, es la idea. Todo el mundo repite "PHP es para hacer cosas pequeñas, rápidas, nada complejo"... porque la verdadera razón es que nosotros somos los pequeños de visión y de conocimientos.

[anthemfor182]

Iniciado por enriqueplace

Estimado, antes de dirigirme la palabra debes de haber sacado todas variables globales de tu framework... digo, por respeto a todos los que usamos POO.

Gracias por el comentario, lo tendré en cuenta, ojala un día de estos me regales una critica sobre el framework en general, admiro mucho tu blog de seguro me serviría mucho para mejorar . Gracias otra vez