Patrones en Symfony - Historial de revisiones

Javiermartin jc: Texto reemplazado: «
» por «»

2019-08-13T19:47:37Z

Texto reemplazado: «<div align="justify">» por «»

Maylen1404ad jc.hlg en 12:49 13 may 2011

2011-05-13T12:49:53Z

Ruslan unhicch: Aplicación de patrones en Symfony trasladada a Patrones en Symfony

2011-05-12T21:17:40Z

Aplicación de patrones en Symfony trasladada a Patrones en Symfony

Yuliet1404ad jc.hlg: /* Patrón MVC */

2011-04-21T12:06:13Z

‎Patrón MVC

Yuliet1404ad jc.hlg: /* Patrones GoF */

2011-04-21T12:04:14Z

‎Patrones GoF

Yuliet1404ad jc.hlg: /* Patrones GRASP */

2011-04-21T11:57:32Z

‎Patrones GRASP

Yuliet1404ad jc.hlg: /* Patrón MVC */

2011-04-21T11:56:09Z

‎Patrón MVC

Maylen1404ad jc.hlg en 15:36 16 abr 2011

2011-04-16T15:36:42Z

Maylen1404ad jc.hlg: Página creada con '{{Ficha Software |nombre= Patrones en Symfony |imagen= Patrones-symfomy.png }}
'''Aplicación de patrones en symfony.''' Para la implementación de [[Symfo...'

2011-04-16T15:33:49Z

Página creada con '{{Ficha Software |nombre= Patrones en Symfony |imagen= Patrones-symfomy.png }} <div align="justify"> '''Aplicación de patrones en symfony.''' Para la implementación de [[Symfo...'

Página nueva

{{Ficha Software
|nombre= Patrones en Symfony
|imagen= Patrones-symfomy.png
}}
<div align="justify">
'''Aplicación de patrones en symfony.''' Para la implementación de [[Symfony|Symfony]] se utilizan varios [[Patrones de diseño y arquitectura|patrones]], situándolos en las capas de Modelo y Control que plantea el patrón arquitectónico MVC.
==Patrones GRASP ==
*Experto: Es uno de los patrones que más se utiliza cuando se trabaja con Symfony, con la inclusión de la librería Propel para mapear la [[Base de Datos|Base de Datos]]. Symfony utiliza esta librería para realizar su capa de abstracción en el modelo, encapsular toda la lógica de los datos y generar las clases con todas las funcionalidades comunes de las entidades, las clases de abstracción de datos (Peer del Modelo) poseen un grupo de funcionalidades que están relacionadas directamente con la entidad que representan y contienen la información necesaria de la tabla que representan.
*Creador: En la clase Actions se encuentran las acciones definidas para el sistema y se ejecutan en cada una de ellas. En dichas acciones se crean los objetos de las clases que representan las entidades, lo que evidencia que la clase Actions es “creador” de dichas entidades. Ejemplos de algunas funciones utilizadas en la clase Actions son: doSelect (), retrieveByPK (), doSelectOne ().
*Alta Cohesión: Symfony permite la organización del trabajo en cuanto a la estructura del proyecto y la asignación de responsabilidades con una alta cohesión. Un ejemplo de ello es la clase Actions, la cual está formada por varias funcionalidades que están estrechamente relacionadas, siendo la misma la responsable de definir las acciones para las plantillas y colaborar con otras para realizar diferentes operaciones, instanciar objetos y acceder a las properties.
*Bajo Acoplamiento: La clase Actions hereda únicamente de sfActions para alcanzar un bajo acoplamiento de clases. Las clases que implementan la lógica del negocio y de acceso a datos se encuentran en el modelo, las cuales no tienen asociaciones con las de la vista o el controlador, lo que proporciona que la dependencia en este caso sea baja.
*Controlador: Todas las peticiones Web son manipuladas por un solo controlador frontal (sfActions), que es el punto de entrada único de toda la aplicación en un entorno determinado. Este patrón se evidencia en las clases sfFrontController, sfWebFrontController, sfContex, los “actions” y el index.php del ambiente.
==Patrones GoF ==
*Patrón Singleton
Clase sfRouting – método getInstance
Esta clase la utiliza el controlador frontal (sfWebFrontController) y se encarga de enrutar todas las peticiones que se hagan a la aplicación. El singleton sfRouting precisa otros métodos muy útiles para la gestión manual de las rutas: ClearRoutes (), hasRoutes (), getRoutesByName ().
*Patrón Command
Este patrón se observa en la clase sfWebFrontController, en el método dispatch(). Esta clase está por defecto y es la encargada de establecer el módulo y la acción que se va a usar según la petición del usuario. Este patrón se aplica además en la clase sfRouting, que está desactivada por defecto y procede según las necesidades del administrador del sistema donde se aplique el framework, la cual se puede activar o desactivar.
En este método es parseada la URL con el objetivo de precisar los parámetros de la misma y de esta forma saber el Actions que debe responder a la petición.
*Patrón Decorator
Este método pertenece a la clase abstracta sfView, padre de todas las vistas, que contienen un decorador para permitir agregar funcionalidades dinámicamente.
El archivo nombrado layout.php es el que contiene el Layout de la página. Este archivo, conocido también como plantilla global, guarda el código HTML que es usual en todas las páginas del sistema, para no tener que repetirlo en cada página. El contenido de la plantilla se integra en el layout, o si se mira desde el otro punto de vista, el layout decora la plantilla. Este procedimiento es una implementación del patrón Decorator.
*Patrón Registry
Este patrón es muy útil para los desarrolladores en la Programación Orientada a Objetos. Este patrón es un medio sencillo y eficiente de compartir datos y objetos en la aplicación sin la necesidad de preocuparse por conservar numerosos parámetros o hacer uso de variables globales. Este patrón se aplica en la clase sfConfig, que es la encargada de acumular todas las variables de uso global en el sistema.
Symfony aplica además el patrón “Front Controller” (Controlador frontal), por lo que posee una estructura bien organizada de controladores, que comienza desde el “index.php” del ambiente y termina en los “Actions”. Cada clase de esta capa tiene su responsabilidad y es única, hay controladores que se encargan de la seguridad del sistema trabajando con ficheros YML, y otros que se encargan de identificar mediante algunos datos las clases que deben realizar determinadas tareas (Patrón GoF Command, clase sfRouting) y las clases relacionadas con la configuración del sistema (sfConfig, y sfConfigHandler).
==Patrón MVC ==
El uso del framework que utiliza MVC obliga a dividir y organizar el código de acuerdo a las convenciones establecidas por el framework. El código de la presentación se guarda en la vista, el código de manipulación de datos se guarda en el modelo y la lógica de procesamiento de las peticiones constituye el controlador. Aplicar el patrón MVC a una aplicación resulta bastante útil además de restrictivo. La implementación que realiza Symfony de la arquitectura MVC incluye varias clases como son:
*sfController: Es la clase del controlador y se encarga de decodificar la petición y transferirla a la acción correspondiente.
*sfRequest: Guarda todos los elementos que integran la petición (parámetros, cookies, cabeceras, etc.)
*sfResponse: Posee las cabeceras de la respuesta y los contenidos. El contenido de este objeto se convierte en la respuesta HTML que se remite al usuario.
*El singleton de contexto (que se obtiene mediante sfContext::getInstance()): Guarda una referencia a todos los objetos que constituyen el núcleo de Symfony y puede ser accedido desde cualquier parte de la aplicación.
Symfony toma lo mejor de la arquitectura MVC y la realiza de modo que el desarrollo de aplicaciones sea rápido y sencillo.
En el controlador se encuentran las acciones, las cuales son el núcleo de la aplicación, pues contienen toda la lógica de la aplicación. Estas acciones utilizan el modelo y precisan las variables para la vista. Al realizarse una petición web en una aplicación Symfony, la URL define una acción y los parámetros de la petición.
La vista es la encargada de originar las páginas que son mostradas como resultado de las acciones, donde se encuentra el layout, que es común para todas las páginas de la aplicación. La vista en Symfony está conformada por varias partes, preparadas cada una de ellas especialmente para ser fácilmente transformable por la persona que normalmente trabaja con cada aspecto del diseño de las aplicaciones.
En el Modelo se encuentran las clases, que son generadas de forma automática según la estructura de la BD. En Symfony, el acceso y la modificación de los datos que se almacenan en la base de datos, se realiza mediante objetos. Propel es el motor generador que se encarga de esta generación automática para construir sus clases, creando la estructura y generando el código de las mismas.
A medida que el desarrollo de un proyecto va avanzando, puede ser necesario agregar métodos y propiedades personalizadas en los objetos del modelo, esto trae consigo que se aumenten las tablas o columnas. Asimismo, cada vez que se modifica se deben regenerar las clases del modelo de objetos. Si se añaden los métodos personalizados en las clases que se generan, cada vez que se vuelvan a generar esas clases estos métodos se borrarían.
Las clases con nombre Base son generadas directamente a partir del esquema. Estas clases no deberían modificarse, ya que cada vez que se genera el modelo, todas las clases se borran. Por otro lado, las clases de objetos propias que heredan de las clases con nombre Base no se modifican, es por ello que son estas clases en las que se añaden los métodos propios. Las mismas heredan todos los métodos de la clase padre correspondiente, pero no son afectadas por las modificaciones en el esquema.
==Fuentes ==
*ZANINOTTO, F. y POTENCIER, F. 2009. librosweb.es. Symfony 1.1, la guía definitiva. [En línea] 2009. http://www.librosweb.es/symfony_1_1.

[[Category:Ciencias_Aplicadas_y_Tecnologías]]

@@ Línea 4: / Línea 4: @@
 }}
 <div align="justify">
-'''Aplicación de patrones en Symfony.''' Para la implementación de [[Symfony|Symfony]] se utilizan varios [[Patrones de diseño y arquitectura|patrones]], situándolos en las capas de Modelo y Control que plantea el patrón arquitectónico MVC.
+'''Patrones en Symfony.''' Para la implementación de [[Symfony|Symfony]] se utilizan varios [[Patrones de diseño y arquitectura|patrones]], situándolos en las capas de Modelo y Control que plantea el patrón arquitectónico MVC.
 ==Patrones GRASP ==
 *'''Experto''': Es uno de los patrones que más se utiliza cuando se trabaja con Symfony, con la inclusión de la librería Propel para mapear la [[Base de Datos|Base de Datos]]. Symfony utiliza esta librería para realizar su capa de abstracción en el modelo, encapsular toda la lógica de los datos y generar las clases con todas las funcionalidades comunes de las entidades, las clases de abstracción de datos (Peer del Modelo) poseen un grupo de funcionalidades que están relacionadas directamente con la entidad que representan y contienen la información necesaria de la tabla que representan.

← Revisión anterior	Revisión del 21:17 12 may 2011
(Sin diferencias)

@@ Línea 35: / Línea 35: @@
 ==Patrón MVC ==
 El uso del framework que utiliza MVC obliga a dividir y organizar el código de acuerdo a las convenciones establecidas por el framework. El código de la presentación se guarda en la vista, el código de manipulación de datos se guarda en el modelo y la lógica de procesamiento de las peticiones constituye el controlador. Aplicar el patrón MVC a una aplicación resulta bastante útil además de restrictivo. La implementación que realiza Symfony de la arquitectura MVC incluye varias clases como son:
-*sfController: Es la clase del controlador y se encarga de decodificar la petición y transferirla a la acción correspondiente.
+*'''sfController''': Es la clase del controlador y se encarga de decodificar la petición y transferirla a la acción correspondiente.
-*sfRequest: Guarda todos los elementos que integran la petición (parámetros, cookies, cabeceras, etc.)
+*'''sfRequest''': Guarda todos los elementos que integran la petición (parámetros, cookies, cabeceras, etc.)
-*sfResponse: Posee las cabeceras de la respuesta y los contenidos. El contenido de este objeto se convierte en la respuesta HTML que se remite al usuario.
+*'''sfResponse''': Posee las cabeceras de la respuesta y los contenidos. El contenido de este objeto se convierte en la respuesta HTML que se remite al usuario.
-*El singleton de contexto (que se obtiene mediante sfContext::getInstance()): Guarda una referencia a todos los objetos que constituyen el núcleo de Symfony y puede ser accedido desde cualquier parte de la aplicación.
+*El singleton de contexto (que se obtiene mediante '''sfContext'''::getInstance()): Guarda una referencia a todos los objetos que constituyen el núcleo de Symfony y puede ser accedido desde cualquier parte de la aplicación.
 Symfony toma lo mejor de la arquitectura MVC y la realiza de modo que el desarrollo de aplicaciones sea rápido y sencillo.
 En el controlador se encuentran las acciones, las cuales son el núcleo de la aplicación, pues contienen toda la lógica de la aplicación. Estas acciones utilizan el modelo y precisan las variables para la vista. Al realizarse una petición web en una aplicación Symfony, la URL define una acción y los parámetros de la petición.

@@ Línea 17: / Línea 17: @@
 ==Patrones GoF ==
-*Patrón Singleton
+*'''Patrón Singleton'''
 Clase sfRouting – método getInstance
 Esta clase la utiliza el controlador frontal (sfWebFrontController) y se encarga de enrutar todas las peticiones que se hagan a la aplicación. El singleton sfRouting precisa otros métodos muy útiles para la gestión manual de las rutas: ClearRoutes (), hasRoutes (), getRoutesByName ().
 *Patrón Command
 Este patrón se observa en la clase sfWebFrontController, en el método dispatch(). Esta clase está por defecto y es la encargada de establecer el módulo y la acción que se va a usar según la petición del usuario. Este patrón se aplica además en la clase sfRouting, que está desactivada por defecto y procede según las necesidades del administrador del sistema donde se aplique el framework, la cual se puede activar o desactivar.
 En este método es parseada la URL con el objetivo de precisar los parámetros de la misma y de esta forma saber el Actions que debe responder a la petición.
 *Patrón Decorator
 Este método pertenece a la clase abstracta sfView, padre de todas las vistas, que contienen un decorador para permitir agregar funcionalidades dinámicamente.
-El archivo nombrado layout.php es el que contiene el Layout de la página. Este archivo, conocido también como plantilla global, guarda el código HTML que es usual en todas las páginas del sistema, para no tener que repetirlo en cada página. El contenido de la plantilla se integra en el layout, o si se mira desde el otro punto de vista, el layout decora la plantilla. Este procedimiento es una implementación del patrón Decorator.
+El archivo nombrado layout.php es el que contiene el Layout de la página. Este archivo, conocido también como plantilla global, guarda el código [[HTML]] que es usual en todas las páginas del sistema, para no tener que repetirlo en cada página. El contenido de la plantilla se integra en el layout, o si se mira desde el otro punto de vista, el layout decora la plantilla. Este procedimiento es una implementación del patrón Decorator.
 *Patrón Registry
 Este patrón es muy útil para los desarrolladores en la Programación Orientada a Objetos. Este patrón es un medio sencillo y eficiente de compartir datos y objetos en la aplicación sin la necesidad de preocuparse por conservar numerosos parámetros o hacer uso de variables globales. Este patrón se aplica en la clase sfConfig, que es la encargada de acumular todas las variables de uso global en el sistema.
-Symfony aplica además el patrón “Front Controller” (Controlador frontal), por lo que posee una estructura bien organizada de controladores, que comienza desde el “index.php” del ambiente y termina en los “Actions”. Cada clase de esta capa tiene su responsabilidad y es única, hay controladores que se encargan de la seguridad del sistema trabajando con ficheros YML, y otros que se encargan de identificar mediante algunos datos las clases que deben realizar determinadas tareas (Patrón GoF Command, clase sfRouting) y las clases relacionadas con la configuración del sistema (sfConfig, y sfConfigHandler).
+[[Symfony]] aplica además el patrón “Front Controller” (Controlador frontal), por lo que posee una estructura bien organizada de controladores, que comienza desde el “index.php” del ambiente y termina en los “Actions”. Cada clase de esta capa tiene su responsabilidad y es única, hay controladores que se encargan de la seguridad del sistema trabajando con ficheros YML, y otros que se encargan de identificar mediante algunos datos las clases que deben realizar determinadas tareas (Patrón GoF Command, clase sfRouting) y las clases relacionadas con la configuración del sistema (sfConfig, y sfConfigHandler).
 ==Patrón MVC ==
 El uso del framework que utiliza MVC obliga a dividir y organizar el código de acuerdo a las convenciones establecidas por el framework. El código de la presentación se guarda en la vista, el código de manipulación de datos se guarda en el modelo y la lógica de procesamiento de las peticiones constituye el controlador. Aplicar el patrón MVC a una aplicación resulta bastante útil además de restrictivo. La implementación que realiza Symfony de la arquitectura MVC incluye varias clases como son:

@@ Línea 6: / Línea 6: @@
 '''Aplicación de patrones en Symfony.''' Para la implementación de [[Symfony|Symfony]] se utilizan varios [[Patrones de diseño y arquitectura|patrones]], situándolos en las capas de Modelo y Control que plantea el patrón arquitectónico MVC.
 ==Patrones GRASP ==
-*Experto: Es uno de los patrones que más se utiliza cuando se trabaja con Symfony, con la inclusión de la librería Propel para mapear la [[Base de Datos|Base de Datos]]. Symfony utiliza esta librería para realizar su capa de abstracción en el modelo, encapsular toda la lógica de los datos y generar las clases con todas las funcionalidades comunes de las entidades, las clases de abstracción de datos (Peer del Modelo) poseen un grupo de funcionalidades que están relacionadas directamente con la entidad que representan y contienen la información necesaria de la tabla que representan.
+*'''Experto''': Es uno de los patrones que más se utiliza cuando se trabaja con Symfony, con la inclusión de la librería Propel para mapear la [[Base de Datos|Base de Datos]]. Symfony utiliza esta librería para realizar su capa de abstracción en el modelo, encapsular toda la lógica de los datos y generar las clases con todas las funcionalidades comunes de las entidades, las clases de abstracción de datos (Peer del Modelo) poseen un grupo de funcionalidades que están relacionadas directamente con la entidad que representan y contienen la información necesaria de la tabla que representan.
 *Creador: En la clase Actions se encuentran las acciones definidas para el sistema y se ejecutan en cada una de ellas. En dichas acciones se crean los objetos de las clases que representan las entidades, lo que evidencia que la clase Actions es “creador” de dichas entidades. Ejemplos de algunas funciones utilizadas en la clase Actions son: doSelect (), retrieveByPK (), doSelectOne ().
-*Alta Cohesión: Symfony permite la organización del trabajo en cuanto a la estructura del proyecto y la asignación de responsabilidades con una alta cohesión. Un ejemplo de ello es la clase Actions, la cual está formada por varias funcionalidades que están estrechamente relacionadas, siendo la misma la responsable de definir las acciones para las plantillas y colaborar con otras para realizar diferentes operaciones, instanciar objetos y acceder a las properties.
+*'''Creador''': En la clase Actions se encuentran las acciones definidas para el sistema y se ejecutan en cada una de ellas. En dichas acciones se crean los objetos de las clases que representan las entidades, lo que evidencia que la clase Actions es “creador” de dichas entidades. Ejemplos de algunas funciones utilizadas en la clase Actions son: doSelect (), retrieveByPK (), doSelectOne ().
 *Bajo Acoplamiento: La clase Actions hereda únicamente de sfActions para alcanzar un bajo acoplamiento de clases. Las clases que implementan la lógica del negocio y de acceso a datos se encuentran en el modelo, las cuales no tienen asociaciones con las de la vista o el controlador, lo que proporciona que la dependencia en este caso sea baja.
-*Controlador: Todas las peticiones Web son manipuladas por un solo controlador frontal (sfActions), que es el punto de entrada único de toda la aplicación en un entorno determinado. Este patrón se evidencia en las clases sfFrontController, sfWebFrontController, sfContex, los “actions” y el index.php del ambiente.
+*'''Alta Cohesión''': Symfony permite la organización del trabajo en cuanto a la estructura del proyecto y la asignación de responsabilidades con una alta cohesión. Un ejemplo de ello es la clase Actions, la cual está formada por varias funcionalidades que están estrechamente relacionadas, siendo la misma la responsable de definir las acciones para las plantillas y colaborar con otras para realizar diferentes operaciones, instanciar objetos y acceder a las properties.
 ==Patrones GoF ==
 *Patrón Singleton

@@ Línea 32: / Línea 32: @@
 Symfony toma lo mejor de la arquitectura MVC y la realiza de modo que el desarrollo de aplicaciones sea rápido y sencillo.
 En el controlador se encuentran las acciones, las cuales son el núcleo de la aplicación, pues contienen toda la lógica de la aplicación. Estas acciones utilizan el modelo y precisan las variables para la vista. Al realizarse una petición web en una aplicación Symfony, la URL define una acción y los parámetros de la petición.
 La vista es la encargada de originar las páginas que son mostradas como resultado de las acciones, donde se encuentra el layout, que es común para todas las páginas de la aplicación. La vista en Symfony está conformada por varias partes, preparadas cada una de ellas especialmente para ser fácilmente transformable por la persona que normalmente trabaja con cada aspecto del diseño de las aplicaciones.
 En el Modelo se encuentran las clases, que son generadas de forma automática según la estructura de la BD. En Symfony, el acceso y la modificación de los datos que se almacenan en la base de datos, se realiza mediante objetos. Propel es el motor generador que se encarga de esta generación automática para construir sus clases, creando la estructura y generando el código de las mismas.
 A medida que el desarrollo de un proyecto va avanzando, puede ser necesario agregar métodos y propiedades personalizadas en los objetos del modelo, esto trae consigo que se aumenten las tablas o columnas. Asimismo, cada vez que se modifica se deben regenerar las clases del modelo de objetos. Si se añaden los métodos personalizados en las clases que se generan, cada vez que se vuelvan a generar esas clases estos métodos se borrarían.
 Las clases con nombre Base son generadas directamente a partir del esquema. Estas clases no deberían modificarse, ya que cada vez que se genera el modelo, todas las clases se borran. Por otro lado, las clases de objetos propias que heredan de las clases con nombre Base no se modifican, es por ello que son estas clases en las que se añaden los métodos propios. Las mismas heredan todos los métodos de la clase padre correspondiente, pero no son afectadas por las modificaciones en el esquema.
 ==Fuentes ==
 *ZANINOTTO, F. y POTENCIER, F. 2009. librosweb.es. Symfony 1.1, la guía definitiva. [En línea] 2009. http://www.librosweb.es/symfony_1_1.
 [[Category:Ciencias_Aplicadas_y_Tecnologías]]

Patrones en Symfony - Historial de revisiones

Javiermartin jc: Texto reemplazado: «» por «»

Maylen1404ad jc.hlg en 12:49 13 may 2011

Ruslan unhicch: Aplicación de patrones en Symfony trasladada a Patrones en Symfony

Yuliet1404ad jc.hlg: /* Patrón MVC */

Yuliet1404ad jc.hlg: /* Patrones GoF */

Yuliet1404ad jc.hlg: /* Patrones GRASP */

Yuliet1404ad jc.hlg: /* Patrón MVC */

Maylen1404ad jc.hlg en 15:36 16 abr 2011

Maylen1404ad jc.hlg: Página creada con '{{Ficha Software |nombre= Patrones en Symfony |imagen= Patrones-symfomy.png }} '''Aplicación de patrones en symfony.''' Para la implementación de [[Symfo...'

Javiermartin jc: Texto reemplazado: «
» por «»

Maylen1404ad jc.hlg: Página creada con '{{Ficha Software |nombre= Patrones en Symfony |imagen= Patrones-symfomy.png }}
'''Aplicación de patrones en symfony.''' Para la implementación de [[Symfo...'