Working on chapter 3
authorgumartinm <gustavo@gumartinm.name>
Wed, 3 Oct 2012 10:06:14 +0000 (12:06 +0200)
committergumartinm <gustavo@gumartinm.name>
Wed, 3 Oct 2012 10:06:14 +0000 (12:06 +0200)
capitulo3/capitulo3.tex
fig/MVC.png [new file with mode: 0644]
myrefs.bib

index 658d761..f997075 100644 (file)
@@ -1,6 +1,6 @@
 \chapter{Herramientas y tecnologías utilizadas}
 
-\section{Full-stack framework}
+\section{Full-stack frameworks}
 
 
 Un \emph{full-stack framework\footnote{Framework en Castellano es traducido como marco de trabajo}}, es una solución que incluye seguridad, enrutamiento de URIs, caché, hooks y muchas otras características. Cuando se usa un framework de estas características el desarrollador se adhiere a los estándares y guías que el framework marca para escribir e implementar el código. Además este tipo de frameworks ofrecen todas las librerías y herramientas que el programador necesita para (en este caso que nos ocupa) desarrollar páginas y servicios Web. Ejemplos de estos frameworks en PHP son:
@@ -26,9 +26,9 @@ Como contra parte a \emph{full-stack frameworks} encontramos los \emph{glue fram
 
 Symfony es un marco de trabajo para el desarrollo de aplicaciones Web escrito en PHP que sigue el paradigma del modelo vista controlador (MVC) Su objetivo es incrementar la velocidad y la eficiencia del desarrollo web. Symfony trae muchas características muy útiles que ayudan a que el desarrollador se concentre en la lógica del negocio de la aplicación en lugar de en la implementación o en los objetos paginadores Web o en las abstracciones con la capada de base de datos. Sin embargo, todo tiene un coste, y es el aprendizaje de cómo usar todas las características que hacen de Symfony un marco de trabajo muy útil~\cite{C3:SymfonyBook14}.
 
-El objetivo de Symfony es acelerar la creación y mantenimiento de aplicaciones web y remplazar tareas de codificación repetitivas. Está diseñado para optimizar el desarrollo de aplicaciones web a través de varias características clave. Así, Symfony separa las reglas de negocio de la aplicación web, de la lógica del servidor y de las vistas o presentación al usuario. Contine numerosas herramientas y clases que permiten acortar el tiempo de desarrollo y aplicaciones web compleja. También automatiza tareas comunes así que el desarrollador puede enfocar su actividad enteramente en las tareas relacionadas con casos específicos de la aplicación. Como resultado final de estas características, con Symfony no hay necesidad de reinventar la rueda cada vez que una nueva aplicación web es construida.
+El objetivo de Symfony es acelerar la creación y mantenimiento de aplicaciones web y remplazar tareas de codificación repetitivas. Está diseñado para optimizar el desarrollo de aplicaciones web a través de varias características clave. Así, Symfony separa las reglas de negocio de la aplicación web, de la lógica del servidor y de las vistas o presentación al usuario. Contiene numerosas herramientas y clases que permiten acortar el tiempo de desarrollo y aplicaciones web compleja. También automatiza tareas comunes así que el desarrollador puede enfocar su actividad enteramente en las tareas relacionadas con casos específicos de la aplicación. Como resultado final de estas características, con Symfony no hay necesidad de reinventar la rueda cada vez que una nueva aplicación web es construida.
 
-Está escrito completamente en PHP y actualmente se usa en sitios web con alta demanda de páginas. Es compatible con la mayoría de servidores de bases de datos disponibles a la fecha como MySQL, PostgreSQL, Oracle y Microsoft SQL Server. Se ejecuta en entors *NIX y Windows.
+Está escrito completamente en PHP y actualmente se usa en sitios web con alta demanda de páginas. Es compatible con la mayoría de servidores de bases de datos disponibles a la fecha como MySQL, PostgreSQL, Oracle y Microsoft SQL Server. Se ejecuta en entornos *NIX y Windows.
 
 \subsection{Características de Symfony}
 
@@ -39,7 +39,7 @@ Symfony ha sido diseñado para alcanzar los siguiente requisitos:
     \item Independiente del tipo de servidor de base de datos.
     \item Simple de usar en la mayoría de casos, pero flexible para adaptarse a casos complejos.
     \item Cumple con la mayoría de prácticas recomendadas para el desarrollo Web así como con muchos patrones de diseño también recomendado para este tipo de desarrollos.
-    \item Código leíble, con phpDocumento para fácil mantenimiento.
+    \item Código leíble, con phpDocumentor para fácil mantenimiento.
     \item Fácil de extender y permite la integración con librerías de otros vendedores.
 \end{itemize}
 
@@ -61,6 +61,50 @@ Las bases de datos son relacionales. PHP y Symfony por otro lado están orientad
 
 Un ORM está constituido de objetos que dan acceso a datos y de reglas de negocio. Un beneficio de una capa de abstracción objeto-relacional es que previene de usar una sintaxis que es específica a una base de datos determinada. Esto significa que migrando de un sistema de base de datos en el medio de un proyecto debería ser fácil.
 
-En el ORM, la capa de abstracción, encapsula la lógica de los datos. El resto de la aplicación no necesita saber las queries SQL y usando los objetos en lugar de las records de la base de datos y clases en lugar de tablas tiene otro beneficio: se pueden añadir nuevos métodos de acceso a las tablas. Por ejemplo si se tiene una tabla llamada Cliente con dos campos, PrimerNombre y Apellido, se puede añadir un nuevo campo Nombre que se compongan de los dos sin necesidad de hacer ninguna modificación el tabla o en la base de datos, simplemente añadiendo un nuevo método al objeto que representa la tabla de la base de datos que devuelva el PrimerNombre y el Apellido concatenados como Nombre.
+En el ORM, la capa de abstracción, encapsula la lógica de los datos. El resto de la aplicación no necesita saber las queries SQL y usando los objetos en lugar de las records de la base de datos y clases en lugar de tablas tiene otro beneficio: se pueden añadir nuevos métodos de acceso a las tablas. Por ejemplo si se tiene una tabla llamada Cliente con dos campos, Nombre y Apellido, se puede añadir un nuevo campo NombreCompleto que se componga de los dos sin necesidad de hacer ninguna modificación en la tabla o en la base de datos, simplemente añadiendo un nuevo método al objeto que representa la tabla de la base de datos que devuelva el Nombre y el Apellido concatenados como NombreCompleto.
 
-Symfony soporta dos ORMs escritos en PHP que son open source: Propel y Doctrine e integra ambos de ellos, cuando se crea un nuevo proyecto se elige qué ORM usar.
+Symfony soporta dos ORMs escritos en PHP que son open source: Propel y Doctrine. Integra ambos y cuando se crea un nuevo proyecto se elige qué ORM usar.
+
+\subsection{El patrón MVC}
+
+Symfony se basa en el patrón de diseño web clásico conocido como arquitectura MVC, la cual consiste de tres niveles:
+
+\begin{itemize}
+\renewcommand{\labelitemi}{$-$}
+    \item El \textbf{Modelo} representa la información con la cual la lógica de negocio de la aplicación opera.
+    \item La \textbf{Vista} renderiza el modelo en una página web adecuada para interactuar con el usuario.
+    \item El \textbf{Controlador} responde a acciones del usuario e invoca cambios en el modelo o en la vista según corresponda.
+\end{itemize}
+
+Además de dividir la aplicación en esos tres niveles arriba citados, el diseño MVC define las interacciones entre cada uno de ellos. En la Figura~\ref{fig:MVC}) se representa el patrón MVC.  
+\begin{figure}[H]
+    \centering
+        \includegraphics[width=0.8\textwidth]{fig/MVC}
+    \caption{\emph{El patrón MVC}}
+    \label{fig:MVC}
+\end{figure}
+
+\subsubsection{El Modelo}
+
+Representa la estructura subyacente de una aplicación Web. Los modelos a menudo son compartidos entre diferentes subaplicaciones de una aplicación Web. Por ejemplo, un modelo LoginForm puede ser usado tanto en el front end como en el back end de una aplicación, también pueden hacer uso del model APIs Web, etc. El modelo debería contener propiedades para representar datos específicos, lógica de negocio como reglas de validación para asegurar que los datos representado se adecuan a los requerimientos de diseño y puede contener código para la manipulación de los datos. En ocasiones, el modelo puede alcanzar proporciones demasiado grandes conteniendo mucho código en una única clase. También puede ser duro de mantener si el código que contiene sirve a diferentes propósitos~\cite{C3:YiiFramework}. De este modo para grandes aplicaciones es conveniente generar una clase base que represente parte del modelo que sea compartido por todas las diferentes subaplicaciones y en cada subapliación se extiende dicha clase base con el código específico para esa subaplicación.
+
+\subsubsection{La Vista}
+
+Representa el modelo en el formato que el usuario final desea. Las vistas, en general deberían cumplir estos puntos:
+
+\begin{itemize}
+    \item Principalmente deben contener código de la capa de presentación, como HTML y código PHP simple para formatear y renderizar daros.
+    \item Debería evitar contener código que realiza queries explícitas a la base de datos. Este código debe estar situado en el modelo.
+    \item La vista puede acceder a propiedades y métodos de controladores y modelos directamente. Sin embargo, esto debería ser realizado solo para presentación.
+\end{itemize}
+
+\subsubsection{El Controlador}
+
+Los controladores enlazan el modelo, la vista y otros componentes de la aplicación. Tratan directamente con peticiones del usuario. 
+
+\begin{itemize}
+    \item Se debe evitar el uso de sentencias SQL directamente en esta capa. Éstas deben ser mantenidas preferiblemente en el modelo.
+    \item No debería contener código HTML o cualquier otro código relacionado con la capa de presentación. Este código es mejor mantenerlo siempre en las vistas.
+\end{itemize}
+
+En una aplicación MVC diseñada correctamente los controladores no contienen mucho código mientras que los modelos sí lo hacen y contienen la mayor parte del código responsable para la representación y manipulación de los datos. Esto se debe a que la estructura de datos y la lógica de negocio representada por los modelos suele ser muy específica para una determinada aplicación, y necesita grandes cambios para lograr los requerimientos de dicho programa; mientras que la lógica del controlador a menudo sigue un modo de funcionamiento similar a través de diferentes aplicaciones y por tanto puede ser simplificado por el framework subyacente o por las clases base~\cite{C3:YiiFramework}.
diff --git a/fig/MVC.png b/fig/MVC.png
new file mode 100644 (file)
index 0000000..926eae8
Binary files /dev/null and b/fig/MVC.png differ
index f4fd3bd..05241c3 100644 (file)
 @Article{C2:LBSprivacy,
     author = {{Janice Y. Tsai, Patrick Gage Kelley, Lorrie Faith Cranor y Norman Sadeh}},
     title = {Location-Sharing Technologies: Privacy Risks and Controls},
+    journal = {CyLab Usable Privacy and Security Laboratory},
     howpublished = "Website",
     note = {\url{http://cups.cs.cmu.edu/LBSprivacy/files/TsaiKelleyCranorSadeh_2009.pdf}},
     publisher = {Carnegie Mellon University},
     year = {2012},
     keywords = "ads, advertising, mobile, opera, report",
 }
+
+@misc{C3:YiiFramework,
+    author = {{Yii Framework}},
+    title = "Best MVC Practices",
+    howpublished = "Website",
+    note = {\url{http://www.yiiframework.com/doc/guide/1.1/en/basics.best-practices}},
+    year = {2012},
+    keywords = "yiiframework, mvc, pattern",
+}