+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}.