ASP.

NET MVC Framework

Modelo Vista Controlador (MVC) es un estilo de arquitectura de software que separa los datos de una aplicación,
la interfaz de usuario, y la lógica de control en tres componentes distintos.

ASP.NET es un entorno para aplicaciones web desarrollado y comercializado por Microsoft. Es usado por
programadores y diseñadores para construir sitios web dinámicos, aplicaciones web y servicios web XML.

El ASP.NET MVC Framework es un framework de aplicaciones web que implementa el patrón modelo-vista-
controlador (MVC). Basado en ASP.NET, permite a los desarrolladores de software construir una
aplicación web como una composición de tres funciones: modelo, vista y controlador. MVC es un patrón de
arquitectura que ayuda a crear una separación lógica entre el modelo (información y lógica de negocio), la vista (la
lógica de presentación) y el controlador (intermediario entre la vista y el modelo).
Uno de los pilares básicos de ASP.NET MVC es el concepto de enrutamiento (routing), lo que permite a las
aplicaciones aceptar peticiones a URL que no se corresponden con ficheros físicos en el servidor. Por ejemplo,
en ASP.NET Web Forms las URL tienen el siguiente formato “http://website/products.aspx?category=dvd” en el que
físicamente existe un fichero products.aspx en la raíz del sitio web. En MVC la misma URL tendría el siguiente
aspecto “http://website/products/dvd” sin que el servidor web necesariamente contenga una carpeta products con
una subcarpeta dvd. De forma predeterminada, ASP.NET MVC enruta las peticiones al controlador y a la vista
adecuada en función de la URL. Es decir, en el ejemplo anterior, nos devolverá la vista dvd del controlador products.
La implementación de Microsoft ASP.NET MVC proporciona una alternativa al modelo de formularios Web Forms
de ASP.NET para crear aplicaciones web. ASP.NET MVC es un marco de presentación de poca complejidad y fácil
de testear que, como las aplicaciones basadas en formularios Web Forms, se integra con características
de ASP.NET como son las páginas maestras y la autenticación basada en pertenencias.

MVC tiene 3 tecnologías…. Web pages, Web forms y MVC

MVC es un patrón, una forma de hacer buenas practicas, la manera recomendada de hacer ciertas cosas es
asignando responsabilidades a los componentes de la aplicación, por ejemplo en una aplicación web debe haber
alguien atendiendo la petición del usuario (Controlador). Otro alguien que tenga acceso a los datos para consultar
la información guardada (Modelo) y otro alguien que se encargue de generar la información que el usuario va a ver
(Vista).

Un Framework, que se podría traducir como marco de trabajo, es el esquema o estructura que se establece y que
se aprovecha para desarrollar y organizar un software determinado. Un Framework sirve para poder escribir código
o desarrollar una aplicación de manera más sencilla. Es algo que permite una mejor organización y control de todo el
código elaborado, así como una posible reutilización en el futuro.

ASP.NET es un framework, un conjunto de clases que nos permiten desarrollar aplicaciones web, ya sea web forms,
web pages, o MVC.

ASP.NET MVC es un framework, un conjunto de clases que nos permiten desarrollar aplicaciones ASP .NET,
utilizando el patrón MVC.

En Visual Studios al crear un proyecto, si estamos trabajando en equipo debemos seleccionar Add to source control.

Aparece el asistente de Windows Studio: donde los muestra las diferentes plantillas Proyecto Vacío (Empty), Web
Forms, MVC, API web, Single Page Application (Aplicación de página única), Azure Mobile Service.

El framework MVC se basa en notaciones de nombre. Crea las capetas en automático.

Pruebas unitarias: si seleccionamos esta opción al crear nuestro proyecto, ésta se encargara de realizar pruebas,
cada vez que se agregue o modifique el código, esto es para comprobar que todo se encuentre funcionando
correctamente… El programador debe escribir los códigos para que se puedan realizar las pruebas y se ejecute
cada vez que se compile la aplicación.

MVC Empty: Genera la estructura de una aplicación MVC que incluye las carpetas de inf. De aplicación como
Properties (assemblies) y References, Los Directorios App_Data, App_Start, Controllers, Models y Views, y los
archivos de configuración Global.asax, Package.config y Web.config.

Un assemblie o ensamblaje es un archivo que el compilador genera automáticamente al compilar con éxito cada
aplicación .NET. Puede ser una biblioteca de enlace dinámico o un archivo ejecutable. Se genera solo una vez para
una aplicación y, en cada compilación posterior el ensamblaje se actualiza. Un ensamblaje consiste en
metadatos. Los metadatos enumeran las características de cada "tipo" dentro del ensamblaje o el binario. Además
de los metadatos, los ensamblajes también tienen un archivo especial llamado Manifest. Contiene información sobre
la versión actual del ensamblaje y otra información relacionada. En .NET, hay dos tipos de ensamblajes, como
Archivo único y Archivo múltiple. Un único conjunto de archivos contiene toda la información requerida (IL,
metadatos y manifiesto) en un solo paquete. La mayoría de los ensamblajes en .NET están compuestos de
ensamblajes de un solo archivo. Los ensamblajes de múltiples archivos se componen de numerosos binarios o
módulos .NET y se generan para aplicaciones más grandes. Uno de los ensamblajes contendrá un manifiesto y otros
tendrán instrucciones de IL y metadatos.

Cuando creamos una nueva aplicación con ASP.NET MVC se crea por defecto una estructura de directorios,
apropiada para la gran mayoría de las aplicaciones. Por supuesto podemos añadir nuevos directorios a esta
estructura, aunque por razones de coherencia recomendamos mantener la estructura que propone ASP.NET MVC.

Carpetas de Información sobre la aplicación:

Properties: La carpeta de propiedades del proyecto, como en cualquier otro proyecto ASP.NET, contiene el archivo
AssemblyInfo.cs donde se encuentra toda la información de la aplicación.

References: La carpeta Referencias contiene las dependencias necesarias para el funcionamiento de la aplicación.
 Carpetas propias de la aplicación:

Directorio App_Data: Esta es la carpeta donde guardaremos los datos de nuestra aplicación web que se
mantengan localmente. Normalmente encontraremos bases de datos (.mdf, .sdf), archivos de datos (xml …) y
cualquier tipo de fichero que actúe como almacén de datos para nuestra aplicación. Este directorio nos sirve para
mejorar la seguridad al usar un archivo de datos local en una aplicación ASP.NET, lo que esté en esta carpeta no se
publicará en la Web.

Directorio App_Start: El directorio contiene los archivos de código que se ejecuta al iniciar la aplicación, para
realizar todas las configuraciones necesarias, al iniciarse la aplicación en ASP.Net MVC. Se configuran algunos
archivos con ciertos contenidos de gran relevancia para la implementación. Toda aplicación ASP.NET MVC es una
instancia derivada de la clase System.Web.HttpApplication, definida en el archivo global.asax. Por defecto contiene
los siguientes archivos(clases):

 BundleConnfig.cs.
 FilterConfig.cs.
 RouteConfig.cs.
 WebApiConfig.cs.

Descripción:

BundleConfig.cs: Esto se utiliza para crear y registrar los paquetes y archivos para CS y JS. Como por
defecto se pueden añadir varios paquetes en este archivo incluyendo jQuery, jQueryUI, la validación de
jQuery, Modernizr y CSS del sitio que por defecto se crea al crear la aplicación.

FilterConfig.cs: Esto se utiliza para crear y registrar filtro globales de MVC error de filtro. Por defecto c
ontiene el filtro HandleErrorAttribute.

RouteConfig.cs: Esto se utiliza para registrar diversos patrones de ruta para su aplicación Asp.Net MVC.
De manera predeterminada, una ruta se ha registrado aquí nombrado como ruta por defecto. Le dice al
motor que debe hacer para reponderle al usuario:
routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); Los archivos .axd no existen físicamente.
ASP.NET usa URL con extensiones .axd (ScriptResource.axd y WebResource.axd) internamente, y son
manejadas por un HttpHandler. Por lo tanto, debe mantener esta regla para evitar que ASP.NET MVC
intente manejar la solicitud en lugar de permitir que el HttpHandler dedicado lo haga.
//Define la ruta de la página de inicio de la aplicacion.
routes.MapRoute(
name: "Default",
url: "{controller}/{action}/{id}",
defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }

WebApiConfig.cs: Esto se utiliza para registrar varias rutas de API WEB similares al de ASP.Net .Net
MVC. Estableciendo los ajustes de configuración adicional de la API WEB.
Directorio Content: Aquí se guardará cualquier tipo de contenido estático que se vaya a mostrar en la web que
estemos construyendo, esto es, imágenes, archivos css, iconos, documentos pdf, videos, etc. Lo normal es crear
subcarpetas dentro con los diferentes tipos de recursos de la aplicación:

ASP.NET MVC nos ofrece por defecto una organización en base a “temas”, que nos permita personalizar el aspecto
visual de nuestra aplicación de forma fácil y rápida (eso en teoría… elaborar un tema visual puede requerir de mucho
trabajo y la colaboración de un diseñador gráfico, algo que recomiendo siempre que sea posible).

También es el lugar apropiado para los archivos .less en el caso de que utilicemos esta tecnología en nuestra
aplicación.

Directorio Controllers: Aquí almacenaremos nuestros controladores, Los cuales tienen la misión de reponder las
peticiones de los usuarios, solicitan datos al modelo, seleccionan la vista apropiada para el usuario y pasan los datos
a la vista para que esta genere el código html y se lo muestre al cliente. Los controladores son las clases
encargadas de recibir y gestionar las peticiones http de la aplicación.

Directorio Filters: El directorio Filters es el lugar donde debemos ubicar los filtros. Los filtros son atributos (también
llamados decoradores) para los controladores, que nos permiten aplicar un comportamiento previo y posterior a la
ejecución de uno o varios métodos de los controladores. Son clases derivadas de
System.Web.Mvc.ActionFilterAttribute. A través de este mecanismo podemos añadir fácilmente funcionalidad a
nuestros controladores evitando repetir la misma lógica una y otra vez, sobrescribiendo el comportamiento de
algunas acciones.

La plantilla incluye un filtro de ejemplo, InitializeSimpleMembership, en el siguiente ejemplo vemos como se utiliza el
fitlro para decorar la clase AccountController (también incluida en la plantilla de proyecto)

[Authorize]
[InitializeSimpleMembership]
public class AccountController : Controller
{
//
 // GET: /Account/Login

Directorio Images: El directorio images es lugar para la imágenes de nuestra aplicación.

Como observación diremos que en el caso de que las imágenes formen parte del aspecto visual del sitio web, y no
del contenido, deberían estar en el directorio content, como parte de un tema.

Por ejemplo, el contenido de una galería fotográfica o de un catalogo de productos debería estas en la
carpeta images, mientras que las imágenes de fondo, iconos de los botones, sprites, etc deberían estar en la
carpeta content junto con los archivos css. Básicamente, si una imagen se utiliza en un archivo css el lugar
adecuado es la carpeta content.

Directorio Models: El directorio models es la ubicación que nos propone ASP.NET MVC para las clases que
representan el modelo de la aplicación, los datos que gestiona nuestra aplicación. Aquí se crean las clases para
almacenar los datos de la entidades. Tradicionalmente el modelo va fuera del proyecto.

Nota. En aplicaciones complejas, divididas en capas las clases de modelo suelen incluirse en assemblie aparte. La
siguiente clase muestra un ejemplo muy básico para representar el modelo de nuestra aplicación.

public class FooModel

{
public Guid Id { get; set; }

public string Name { get; set; }

}

Una de las grandes ventajas de las que disponemos en ASP.NET es que podemos decorar la clase que representa
la modelo con diferentes atributos, que nos van a permitir establecer reglar sobre los datos como por ejemplo las
reglas de la validación, si el datos es requerido o no, la longitud máxima y mínima del dato … etc

public class FooModel

{
[Required]
 public Guid Id { get; set; }

[Required]
[StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 3)]
[Display(Name = "Name for FooModel")]
public string Name { get; set; }
}

Directorio Scripts: El directorio scripts está pensado para ubicar los archivos de javascript (*.js). El código javascript
es ejecutado en el contexto del navegador, es decir, en la parte cliente, y nos permite ejecutar acciones sin
necesidad de enviar los datos al servidor.

ASP.NET MVC incluye varias librerias de javascript por defecto:

 jquery.js. Esta popular y súper útil librería nos va a permitir gestionar fácilmente peticiones AJAX, manipular el DOM
en cliente, etc … Esta librería se ha convertido en un framework muy popular, y es la base de para la creación
de pluggins que nos van a permitir dotar a nuestro sitio web de efecto sorprendentes sin apenas
esfuerzo. http://jquery.com/
 jquery.spin.js. Este pluggin nos permite crear animaciones de indicación de carga de contenidos – el circulito que
da vueltas para indicarnos que la página esta realizando algún proceso . Es un pluggin de jQuery basado en
spin.js. http://fgnass.github.io/spin.js/
 jquery.validate.js. Este pluggin nos permite realizar validaciones en el lado cliente fácilmente. Esta vinculado al uso
de decoradores en el modelo de nuestra aplicación.
 knockout.js. Esta librería nos permite utilizar el patrón de diseño MVVM (Model View ViewModel), que introdujo
Microsoft para el desarrollo con WPF y Silverlight en aplicaciones web con javascript. http://knockoutjs.com/
 modernizr.js. Esta librería nos permite validar fácilmente si el navegador que esta ejecutando la página web es
compatible con HTML5, en en caso de que no sea así proporcional un mecanismo alternativo
(polyfill). http://modernizr.com/. Por ejemplo, si nuestro navegador es compatible con HTML5 interpretará sin
problema la etiqueta VIDEO, pero en el caso de que estemos navegando con un navegador antiguo deberemos
ofrecer al usuario un mecanismo alternativo para el video (un flash por ejemplo). En el siguiente enlace podemos
encontrar polyfills para casi todas las características de HTML5: https://github.com/Modernizr/Modernizr/wiki/HTML5-
Cross-Browser-Polyfills
Directorio Views: El directorios Views contiene los archivos de vista. Como explicamos en la introducción al patrón
MVC los controladores devuelven vistas sobre las que inyectamos el modelo de nuestra aplicación. Estas vistas son
interpretadas por el motor de renderización – Razor en nuestro caso. Son archivos similares a aplicaciones de ASP
clasico, donde tenemos código HTML estático y determinadas zonas de código que son ejecutadas en el servidor.

Dentro del directorio Vistas se encuentra un archivo Web.config: en este archivo de configuración solo aplica a este
contenedor.

Aquí hay motores de Vista los cuales se encargan de procesar el código html y c#, hay 2 motores de vita
tradicionales, el motor de vistas Razor: Razor es una sintaxis de marcado para insertar código basado en servidor en
páginas web. La sintaxis de Razor combina marcado de Razor, C# y HTML. Los archivos que contienen sintaxis de
Razor suelen tener la extensión de archivo .cshtml. El lenguaje de Razor predeterminado es HTML. Representar el
HTML del marcado de Razor no difiere mucho de representar el HTML de un archivo HTML. El marcado HTML de los
archivos de Razor .cshtml se representa en el servidor sin cambios. Sintaxis de Razor : Razor admite C# y usa el
símbolo @ para realizar la transición de HTML a C#. Razor evalúa las expresiones de C# y las representa en la salida
HTML. Cuando el símbolo @ va seguido de una palabra clave reservada de Razor, realiza una transición a un marcado
específico de Razor; en caso contrario, realiza la transición a C# simple.
Para hacer escape en un símbolo @ en el marcado de Razor, use un segundo símbolo @:
CSHTMLCopiar
<p>@@Username</p>
El código aparecerá en HTML con un solo símbolo @:
HTMLCopiar
<p>@Username</p>
El contenido y los atributos HTML que tienen direcciones de correo electrónico no tratan el símbolo @ como un
carácter de transición. El análisis de Razor no se detiene en las direcciones de correo electrónico del siguiente
ejemplo:
CSHTMLCopiar
<a href="mailto:Support@contoso.com">Support@contoso.com</a>

El siguiente ejemplo muestra el clásico “Hola Mundo”.

@{
Layout = "~/Views/Shared/_Layout.cshtml";
ViewBag.Title = "HelloWorld";
}
<h2>HelloWorld</h2>
@*El código de servidor se especifica con el caracter @*@

Podemos asignar un modelo a la vista a través de la siguiente directiva.

 @model MvcApplication1.Models.FooModel

Directorio Shared

El directorio Shared contiene vistas que van a ser reutilizadas en otras vistas. Veremos como incluir vistas -
denominadas parciales – en otra vista cuando veamos Razor, aunque de manera muy breve diremos que se realiza
a través del Helper Html, de la siguiente forma:

@Html.Partial("Error") @*Incluye la vista parcial Error.cshtml, del directorio Shared*@

En este caso es muy importante respetar la ubicación de los archivos, ya que cuando desde una vista hagamos la
llamada @Html.Partial(“Error”) para incluir la vista de la pantalla de error, el motor buscara en el directorio Shared
para encontrar la vista Error.cshtml.

No debemos confundir una vista compartida con los controles .ascx de ASP.NET WebForms. Cuando incluimos
vistas compartidas en otra vista, esta son interpretadas por RAZOR sin ejecutarse ningún controlador. Simplemente
se renderiza su contenido – no como en los controles ascx donde se ejecuta todo el ciclo de vida del control
completo y sus correspondientes eventos.

Es posible utilizar una vistas compartida de un modo muy similar al de un control ascx de ASP.NET WebForms,
aunque para este debemos forzar la ejecución del controlador a través de los métodos Action y RenderAction
del Helper Html:

@Html.Action("About") @*Ejecuta el método "About" del controlador correspondiente*@

Archivo _ViewStart.cshtml

Este archivo establece el layout por defecto de las páginas. El contenido del archivo es sencillo y únicamente
especifica el archivo de layout.

@{
Layout = "~/Views/Shared/_Layout.cshtml";
}

El layout es un archivo con extension .cshtml que contiene la estructura general de documento, que es reutilizada en
el resto de vistas. De este modo evitamos tener que reescribir el código en todas las vistas, reutilizando el código y
permitiendo que este sea mucho mas sencillo de mantener.

En cierto modo es similar a las MasterPages de ASP.NET WebForms.

Archivo _Layout.cshtml

El archivo _Layout.cshtml define el layout de la aplicación, que contiene la estructura general de documento, que es
reutilizada en el resto de vistas. El archivo _Layout.cshtml se encuentra dentro del directorio Views/Shared. El
contenido del archivo layout por defecto se muestra a continuación:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>@ViewBag.Title - My ASP.NET MVC Application</title>
<link href="~/favicon.ico" rel="shortcut icon" type="image/x-icon" />
 <meta name="viewport" content="width=device-width" />
@Styles.Render("~/Content/css")
@Scripts.Render("~/bundles/modernizr")

</head>
<body>
<header>
<div class="content-wrapper">
<div class="float-left">
<p class="site-title">@Html.ActionLink("your logo here", "Index", "Home")</p>
</div>
<div class="float-right">
<section id="login">
@Html.Partial("_LoginPartial")
</section>
<nav>
<ul id="menu">
<li>@Html.ActionLink("Home", "Index", "Home")</li>
<li>@Html.ActionLink("About", "About", "Home")</li>
<li>@Html.ActionLink("Contact", "Contact", "Home")</li>
</ul>
</nav>
</div>
</div>
</header>
<div id="body">
@RenderSection("featured", required: false)
<section class="content-wrapper main-content clear-fix">
@RenderBody()
</section>
</div>
<footer>
<div class="content-wrapper">
<div class="float-left">
<p>&copy; @DateTime.Now.Year - My ASP.NET MVC Application</p>
</div>
</div>
</footer>

@Scripts.Render("~/bundles/jquery")
@RenderSection("scripts", required: false)
</body>
</html>

Fijemonos en la llamada que hace Razor al método @RenderBody(), es ahí donde se procesará la vista que
estemos mostrando.

Podemos tener múltiples archivos de layout dentro de nuestro proyecto.

 Archivos de Configuración:

El archivo web.config es el archivo principal de configuración de ASP.NET. Se trata de un archivo XML donde se
define la configuración de la aplicación. Veremos poco a poco el contenido de este fichero, aunque vamos a ver aquí
algunas características generales que es necesario conocer. El archivo web.config contiene información que controla
la carga de módulos, configuraciones de seguridad, configuraciones del estado de la sesión, opciones de
compilación y el lenguaje de la aplicación.
 Control de seguridad.
 Conexiones a bases de datos.
 Estado de las sesiones.
 Control de errores.
 Configuraciones personalizadas.
 Al igual que el global.asax debe ser colocado en la raíz de la aplicación.

Para simplificar el despliegue de las aplicaciones, el archivo de configuración se presenta en diferentes versiones, de
forma que podemos modificar el archivo de configuración dependiendo de nuestra configuración de despliegue. Si
observamos estos archivos observaremos que contienen transformaciones XML que se aplican sobre el archivo
web.config al desplegar la aplicación. De este modo cuando desplegamos la aplicación en modo Debug se aplicarán
las transformaciones XML definidas en Web.Debug.config.

El archivo de configuración aplica un mecanismo de jerarquía a nivel de los archivos de configuración, en la que un
archivo de mayor profundidad dentro de la jerarquía sobrescribe al de menor, en el contexto del recurso solicitado.

Por ejemplo, si dentro de nuestra aplicación tenemos un archivo web.config sobre la raíz del sitio (en gris sobre la
imagen), y otro sobre la carpeta Views (en rojo), el archivo de configuración de la carpeta Views prevalece y
sobrescribe el valor del archivo de configuración raiz (siempre que el recurso solicitado sea se encuentre el
directorio, en este ejemplo Views).
De esta forma podemos por ejemplo establecer en nuestro sitio web “areas” públicas y privadas de manera muy
sencilla, tan fácil separar los archivo en directorios, es como incluir un archivo de configuración con la seguridad
activada sobre el directorio privado, y otro accesible a todo el mundo en el directorio privado.

Cada aplicación web en ASP.NET hereda su web.config base desde el web.config de la máquina localizado en
%SystemRoot%\Microsoft.Net\Framework\v#.#.#.#\CONFIG, aunque secciones individuales pueden ser asignadas
en el web.config principal usando la directiva <location> y bloqueos utilizando el elemento allowOverride.1
<customErrors>
Secciones de un web.config
Como hemos comentado hay múltiples secciones que pueden ser configurados dentro del web.config, a
continuación vemos un ejemplo con las más comunes:

<configuration>
<configSections>
…
</configSections>

<!--Sección de variables de app.

Aquí pueden declararse variables a usar en toda la aplicación.-->
<appSettings>
<add key="key1" value="value1" />
<add key="key2" value="value2" />
</appSettings>

<system.web>
<httpModules>

</httpModules>

<!--Tamaño máximo de las peticiones-->

<httpRuntime maxRequestLength="1024000" executionTimeout="3600" />

<!--Configuración de las sessiones-->

<sessionState timeout="60" />

<!--Habilitando y estableciendo duración de las cookies-->

<sessionState cookieless="true" timeout="10"/>

<!--Permisos de seguridad-->
<authorization>
...
</authorization>

<compilation>
<!--Ensamblados de la app-->
<assemblies>
...
</assemblies>
</compilation>
</system.web>
</configuration>

Cómo se ve, la configuración es muy sencilla, usando etiquetas xml es posible configurar casi todos los parámetros
del servidor.

Otros modulos configurables en el web.config

Establecer permisos de seguridad para cada sección de la web. Es posible añadir un web.config particular en una
carpeta en la que desees establecer un nivel de seguridad con un rol de usuario. Para ello es tan sencillo como crear
un nuevo web.config y añadir las siguientes líneas:

 <system.web>
 <authorization>
 <allow roles="Administrador,Editor" />
 <deny users="*" />
 </authorization>
 </system.web>

En este ejemplo vemos como permitimos la entrada a esta sección a los administradores y editores, negándoselo al
resto de usuario. También es posible establecer reglas de enrutamiento para las urls de la aplicación. Con esto
podemos crear url’s amigables en cualquier web. Puede ser usado para muchas más cosas como declarar y
configurar módulos externos de .net, como librerías para el cache, filtrados de rangos de ips, etc..

El archivo packages.config se usa en algunos tipos de proyecto para mantener la lista de paquetes a los que hace
referencia el proyecto. Esto permite que NuGet restaure fácilmente las dependencias del proyecto cuando el
proyecto se debe transportar a otro equipo (por ejemplo, a un servidor de compilación) sin todos estos paquetes.

Si usa, packages.config normalmente se encuentra en una raíz del proyecto. Se crea automáticamente cuando se
ejecuta la primera operación de NuGet, pero también pueden crearse manualmente antes de ejecutar cualquier
comando, como nuget restore.

Los proyectos que utilizan PackageReference no usan packages.config.

Schema

El esquema es sencillo: a continuación del encabezado XML estándar hay un nodo <packages> que contiene uno o
varios elementos <package>, uno para cada referencia. Cada elemento <package>puede tener los siguientes
atributos:

Atributo Obligatorio Descripción

Id Sí Identificador del paquete, como Newtonsoft.json o

Microsoft.AspNet.Mvc.

Versión Sí Versión exacta del paquete que se va a instalar (por ejemplo, 3.1.1
o 4.2.5.11-beta). Una cadena de versión debe tener al menos tres
números; un cuarto es opcional, ya que se trata de un sufijo de
versión preliminar. No se admiten intervalos.

targetFramework No Moniker de la versión de .NET Framework de destino (TFM)que se

va a aplicar al instalar el paquete. Se establece inicialmente en el
destino del proyecto cuando se instala un paquete. Como resultado,
puede haber distintos elementos <package> que tengan TFM
diferentes. Por ejemplo, si crea un proyecto destinado a .NET 4.5.2,
los paquetes instalados en ese punto usarán el TFM de net452. Si
más adelante redestina el proyecto a .NET 4.6 y agrega más
paquetes, usarán el TFM de net46. Si hay discrepancias entre el
destino del proyecto y los atributos targetFramework, se generarán
advertencias, en cuyo caso puede volver a instalar los paquetes
afectados.
Atributo Obligatorio Descripción

allowedVersions No Se aplicó un intervalo de versiones admitidas para este paquete

durante la actualización del paquete (vea Restringir las versiones de
actualización). No afecta al paquete que se instala durante una
operación de instalación o de restauración. Vea Package
versioning (Control de versiones de paquetes) para consultar la
sintaxis. La interfaz de usuario del administrador de paquetes
también deshabilita todas las versiones que se encuentren fuera del
intervalo permitido.

developmentDependency No Si el proyecto de consumo en cuestión crea un paquete de NuGet,

el hecho de establecerlo en true para una dependencia impide que
ese paquete se incluya cuando se cree el paquete de consumo. De
manera predeterminada, es false.

Ejemplos

El siguiente archivo packages.config hace referencia a dos dependencias:

XMLCopiar

<?xml version="1.0" encoding="utf-8"?>

<packages>
<package id="jQuery" version="3.1.1" targetFramework="net46" />
<package id="NLog" version="4.3.10" targetFramework="net46" />
</packages>

El siguiente archivo packages.config hace referencia a nueve paquetes, pero Microsoft.Net.Compilers no se incluirá
al crear el paquete de consumo debido al atributo developmentDependency. La referencia al archivo
Newtonsoft.Json también restringe las actualizaciones únicamente a las versiones 8.x y 9.x.

XMLCopiar

<?xml version="1.0" encoding="utf-8"?>

<packages>
<package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.0" targetFramework="net46" />
<package id="Microsoft.Net.Compilers" version="1.0.0" targetFramework="net46" developmentDependency="true"
/>
<package id="Microsoft.Web.Infrastructure" version="1.0.0.0" targetFramework="net46" />
<package id="Microsoft.Web.Xdt" version="2.1.1" targetFramework="net46" />
<package id="Newtonsoft.Json" version="8.0.3" allowedVersions="[8,10)" targetFramework="net46" />
<package id="NuGet.Core" version="2.11.1" targetFramework="net46" />
<package id="NuGet.Server" version="2.11.2" targetFramework="net46" />
<package id="RouteMagic" version="1.3" targetFramework="net46" />
<package id="WebActivatorEx" version="2.1.0" targetFramework="net46" />
</packages>

global.asax
El global.asax es el archivo de aplicación para todo proyecto ASP.NET, se encuentra en la raíz del proyecto. En él se
declaran todos los eventos a nivel de aplicación como el inicio y fin de la misma, las peticiones web, etc... Es la
evolución del antiguo global.asa existente en entornos de ASP clásico.
Se compila cada vez que inicia la aplicación. Cualquier modificación del archivo es detectada y origina el reinicio de la
misma.

Toda aplicación ASP.NET MVC es una instancia de una clase derivada de System.Web.HttpApplication. Esta clase es el punto de entrada de
nuestra aplicación – el Main de la aplicación web por decirlo de alguna manera. Como podemos observar, la clase base es la misma que para
una aplicación ASP.NET clásica (WebForms) por lo que todos que podemos reutilizar todo lo que ya sabíamos de ASP.NET.

Desde este archivo podemos manejar eventos a nivel de aplicación, sesión, cache, autenticacion, etc ...

Este archivo varia mucho desde la versión anterior de ASP.NET MVC, aunque el funcionamiento es el mismo. En ASP.NET MVC 4 se ha incluido
el directorio App_Start que nos permite organizar como se inicializa la aplicación.

// Por defecto, el namespace corresponde con el nombre del proyecto

namespace MvcApplication1
{
public class MvcApplication : System.Web.HttpApplication
{
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
WebApiConfig.Register(GlobalConfiguration.Configuration);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
BundleConfig.RegisterBundles(BundleTable.Bundles);
AuthConfig.RegisterAuth();
}
}
}

Como podemos ver, el código se encarga de registrar las áreas definidas en el proyecto, cargar la configuración, filtros, etc…, en definitiva, se
encarga de configurar la aplicación para que esta pueda ejecutar de manera correcta. Las clases de configuración se encuentran en el
directorio App_Start

En el siguiente enlace podemos encontrar la documentación oficial sobre el archivo global.asax http://msdn.microsoft.com/en-
us/library/1xaas8a2(v=vs.71).aspx

La lista completa de eventos disponibles es la siguiente:

// Summary:
// Occurs when ASP.NET acquires the current state (for example, session state)
// that is associated with the current request.
public event EventHandler AcquireRequestState;
//
// Summary:
// Occurs when a security module has established the identity of the user.
public event EventHandler AuthenticateRequest;
//
// Summary:
// Occurs when a security module has verified user authorization.
public event EventHandler AuthorizeRequest;
//
// Summary:
// Occurs as the first event in the HTTP pipeline chain of execution when ASP.NET
// responds to a request.
public event EventHandler BeginRequest;
//
// Summary:
// Occurs when the application is disposed.
public event EventHandler Disposed;
//
// Summary:
// Occurs as the last event in the HTTP pipeline chain of execution when ASP.NET
// responds to a request.
public event EventHandler EndRequest;
//
// Summary:
// Occurs when an unhandled exception is thrown.
public event EventHandler Error;
//
// Summary:
// Occurs just before ASP.NET performs any logging for the current request.
public event EventHandler LogRequest;
//
// Summary:
// Occurs when the handler is selected to respond to the request.
public event EventHandler MapRequestHandler;
//
// Summary:
// Occurs when the request state (for example, session state) that is associated
// with the current request has been obtained.
public event EventHandler PostAcquireRequestState;
//
// Summary:
// Occurs when a security module has established the identity of the user.
public event EventHandler PostAuthenticateRequest;
//
// Summary:
// Occurs when the user for the current request has been authorized.
public event EventHandler PostAuthorizeRequest;
//
// Summary:
// Occurs when ASP.NET has completed processing all the event handlers for the
// System.Web.HttpApplication.LogRequest event.
public event EventHandler PostLogRequest;
//
// Summary:
// Occurs when ASP.NET has mapped the current request to the appropriate event
// handler.
public event EventHandler PostMapRequestHandler;
//
// Summary:
// Occurs when ASP.NET has completed executing all request event handlers and
// the request state data has been stored.
public event EventHandler PostReleaseRequestState;
//
// Summary:
// Occurs when the ASP.NET event handler (for example, a page or an XML Web
 // service) finishes execution.
public event EventHandler PostRequestHandlerExecute;
//
// Summary:
// Occurs when ASP.NET bypasses execution of the current event handler and allows
// a caching module to serve a request from the cache.
public event EventHandler PostResolveRequestCache;
//
// Summary:
// Occurs when ASP.NET finishes updating caching modules and storing responses
// that are used to serve subsequent requests from the cache.
public event EventHandler PostUpdateRequestCache;
//
// Summary:
// Occurs just before ASP.NET starts executing an event handler (for example,
// a page or an XML Web service).
public event EventHandler PreRequestHandlerExecute;
//
// Summary:
// Occurs just before ASP.NET sends content to the client.
public event EventHandler PreSendRequestContent;
//
// Summary:
// Occurs just before ASP.NET sends HTTP headers to the client.
public event EventHandler PreSendRequestHeaders;
//
// Summary:
// Occurs after ASP.NET finishes executing all request event handlers. This
// event causes state modules to save the current state data.
public event EventHandler ReleaseRequestState;
//
// Summary:
// Occurs when the managed objects that are associated with the request have
// been released.
public event EventHandler RequestCompleted;
//
// Summary:
// Occurs when ASP.NET finishes an authorization event to let the caching modules
// serve requests from the cache, bypassing execution of the event handler (for
// example, a page or an XML Web service).
public event EventHandler ResolveRequestCache;
//
// Summary:
// Occurs when ASP.NET finishes executing an event handler in order to let caching
// modules store responses that will be used to serve subsequent requests from
// the cache.
public event EventHandler UpdateRequestCache;

Eventos del global.asax

Entre todos los eventos global.asax, cabe destacar como principales los siguientes:

 Application_Init: Inicio de la aplicación

 Application_Disposed: Se dispara justo antes de que una aplicación sea destruida. Este método es ideal
para limpiar anteriormente recursos que fueron utilizados.
 Application_Start: Se dispara cuando se ha creado la primera instancia de la clase HttpApplication. Esto
permite crear objetos que son accesibles a las todas las instancias de HttpApplication.
 Application_End: Último evento lanzado antes de finalizar por completo la aplicación.
 Application_Error: Se ejecuta cuando salta un error no controlado dentro de la aplicación.
 Application_BeginRequest: Evento lanzado por cada petición de un cliente, ya sea el acceso a una url, una
imagen, etc...
 Application_EndRequest: Último evento antes de dar finalizada una petición.
 Session_Start: Nueva sesión iniciada por un usuario. Muy usado junto al session_end para establecer
contadores de usuarios activos.
 Session_End: Fin de sesión para un usuario.

Usos del global.asax

Puede ser usado para múltiples tareas de gestión de las aplicaciones. Unos ejemplos pueden ser:

 Declaración de filtros globales en el global.asax.

 Interactuar con todas las peticiones. Puede usarse para gestionar las peticiones, modificar variables de app,
crear un log de las mismas, etc...
 Declarar modulos como el propio enrutado de asp.net.
 Gestionar los errores de la aplicación. Recogiendo los mismos dentro del evento onApplicationError, se
puede establecer un control de estos, guardando un log y gestionando las redirecciones según el
tratamiento deseado

__________________________________________________________________________________________

Primero comenzamos agregado un controlador: El controlador es una clase que hereda de

System.Web.Mvc.Controller, el cual tiene distintas funcionalidades, las cuales se pueden consultar dando clic
derecho sobre Controller y en la opción ir a definición. Redireccionamientos, Json, Retomar vistas…

HomeController.cs
//desclaramos espacios de nombres a utilizar
// espacio de nombre de los modelos de la aplicacion
using DemoMVC14972019.Models;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
//creamos un espacio de nombre para la Aplicación.
namespace DemoMVC14972019.Controllers
{
/* http://host/Home/index, declaramos la clase para el controlador
public class HomeController : Controller
{
// GET: Home - Asgnamos la accion o metodo Index, ActionResult es una clase abstracta
responsable de devolver el contenido al navegador o al script de llamada.
public ActionResult Index()
{
//creamos un nuevo objeto con la clase Repositorio
Repositorio R = new Repositorio();
//Creamos una variable
var Model = R.GetDemo();
//Agregamos el Modelo a la Vista
return View(Model);
} } }
HomeContoller
La clase HomeController es el punto de entrada de la aplicación, la página por defecto.
Cuando creamos un nuevo proyecto ASP.NET MVC se crea también un controlador HomeController situado directamente el folder Controllers.

El controlador de ejemplo que se incluye en el proyecto por defecto, incluye tres métodos: Index, About y Contact, que disponen de sus
correspondiente vistas en el folder Home.

El código del HomeController es el siguiente:

namespace MvcApplication1.Controllers
{
public class HomeController : Controller
{
public ActionResult Index()
{
ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";

return View();
}

public ActionResult About()

{
ViewBag.Message = "Your app description page.";
 return View();
}

public ActionResult Contact()

{
ViewBag.Message = "Your contact page.";

return View();
}
}
}

Creamos dos modelos : Demo y Repositorios

DEMO.cs:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

//Espacio de nombres
namespace DemoMVC14972019.Models
{
//Clase del modelo Demo
public class Demo
{
//Declaramos las propiedades
public string Mensaje { get; set; }
public string MensajeHTML { get; set; }
}
}

REPOSITORIO.cs:

using System.Collections.Generic;
using System.Linq;
using System.Web;

//creamos un espacio de nombre

namespace DemoMVC14972019.Models
{
//creamos la clase Repositorio
public class Repositorio
{
//Creamos metodo o procedimiento publico que devuelva un texto
public Demo GetDemo()
{
//devuleve el valor
return new Demo
{
Mensaje = "Hola mundo!!!",
MensajeHTML = "<h1>Hola mundo!!!</h1>"
};
}
}
}

Creamos una vista Index.cshtml

@* Sitaxys Razo para definir un bloque de codigo: *@

@* Sintaxys razor y traemos el modelo *@

@model DemoMVC14972019.Models.Demo

@{
@* el siguiente codigo dice que no utiliza ningun masterpage *@
Layout = null;
}

<!DOCTYPE html>

<html>
<head>
<meta name="viewport" content="width=device-width" />
<title>Index</title>
</head>
<body>
<div>
Esta es una vista sin modelo!
</div>
<div>
@Model.Mensaje
</div>
<div>
<h1>@Model.MensajeHTML</h1>

</div>
<div>
<!--Escribe como llega el texto-->
@Html.Raw(Model.MensajeHTML)
</div>
</body>
</html>

Como utilizar Repositos y EntityFramework.

5 - Controller - View - Model

En un primer paso resolvimos toda la lógica de nuestra aplicación web solo con el "Controlador", en un
segundo paso separamos las actividades agrupando funcionalidades en el "Controlador" y la "Vista". Ahora
implementaremos otro problema elemental pero introduciendo los tres elementos fundamentales de este
patrón de programación: "Modelo", "Vista" y "Controlador".
Recordemos que cada una de las componentes del patrón MVC tienen un objetivo bien definido:

 Controlador: Es una clase o conjunto de clases que coordinan la comunicación entre las peticiones
que hace el cliente (Navegador generalmente), el modelo que procesa los datos que llegan del
cliente y comunica a las vistas para que muestren los datos peticionados por el cliente.

 Vistas: Definen como se mostrará la interfaces de usuario de la aplicación.

 Modelos: Se implementan las clases que resuelven la lógica de negocios de nuestra aplicación.

Problema
Desarrollar un libro de visitas a un sitio web. Debe haber un formulario que permita ingresar el nombre del
visitante y los comentarios. Almacenar los datos en un archivo de texto.
La página principal debe tener dos hipervínculos. El primero que acceda a un formulario web para la carga del
nombre del visitante y sus comentarios y el segundo hipervínculo debe mostrar todos los comentarios que han
dejado los visitantes al sitio web.
Resolveremos el problema enunciando uno a uno los pasos que debemos dar en el Visual Studio .Net para ir
creando y codificando cada uno de los archivos necesarios en las carpetas "Controllers", "Views" y "Models".
1. Creamos el proyecto (Proyecto4)
Creación del proyecto. Para esto seleccionamos desde el menú la opción "Archivo" -> "Nuevo" ->
"Proyecto..."

Aparece un diálogo donde debemos indicar del lado izquierdo que utilizaremos el lenguaje Visual C#
y del lado de la derecha seleccionamos "Aplicación web ASP.NET (.Net Framework)" y en la parte
inferior definimos el "nombre", "ubicación" y "nombre de la solución" (podemos usar el mismo texto
para el "nombre de la solución" y "nombre"):

Aparece un segundo diálogo donde seleccionaremos que cree un proyecto vacío y utilice el patrón
MVC:

2. Ahora creamos el "Controlador" como hicimos en conceptos anteriores.

El controlador principal siempre lo llamaremos "Home", para esto presionamos el botón derecho del
mouse sobre la carpeta "Controllers" y seleccionar "Agregar" -> Controlador...:

En el diálogo seleccionamos "Controlador de MVC 5: en blanco":

 En el diálogo siguiente damos como nombre "HomeController" (por convención en ASP.NET MVC
todos los controladores terminan con la palabra "Controller"):

Ahora si vemos el "Explorador de soluciones" podremos comprobar que en la carpeta "Controllers"

tenemos un archivo llamado "HomeController.cs":

También se creó una carpeta llamada Home en la carpeta Views, en esta carpeta guardaremos las
vistas para cada acción que definamos en el controlador.

3. Ahora generaremos la vista para la página principal del sitio, como sabemos tenemos que abrir el
archivo HomeController y presionar el botón derecho del mouse sobre el método Index:

El nombre de la vista la dejamos con el nombre propuesto "Index", la plantilla debe ser "Empty (sin
modelo) y finalmente sacamos el Check del "Usar página de diseño" (para evitar que se agreguen
otros archivos que veremos más adelante y que hace más complejo el problema):

Si vemos ahora el "Explorador de soluciones" podemos observar que se ha creado un archivo

llamado "Index.cshtml" en la carpeta "Views", subcarpeta "Home".
El contenido de este archivo lo modificamos para que muestre los dos enlaces de nuestro sitio web:

@{
Layout = null;
}

<!DOCTYPE html>

<html>
<head>
<meta name="viewport" content="width=device-width" />
<title>Index</title>
</head>
<body>
<div>
<p><a href="/Home/FormularioVisita">Dejar comentarios
en el libro de visitas.</a></p>
<p><a href="/Home/ListadoVisitas">Comentarios de
visitantes.</a></p>
</div>
</body>
</html>

Ya podemos ejecutar la aplicación y ver la página principal del sitio web propuesto:

Crearemos ahora la vista que muestra el formulario donde el visitante dejará sus comentarios. Lo
primero que hacemos es modificar el archivo HomeController agregando otro método:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;

namespace Proyecto4.Controllers
{
public class HomeController : Controller
{
// GET: Model
public ActionResult Index()
{
return View();
}

public ActionResult FormularioVisita()

{
return View();
 }
}
}

Hemos planteado el método FormularioVisita que sabemos que se ejecutará cuando el usuario
ingrese la URL:

http://localhost/Home/FormularioVisita

Esto sucede cuando el visitante elige el primer enlace de la vista "Index.cshtml".

Debemos crear la vista asociada al método FormularioVisita(), como ya sabemos presionamos el

botón derecho del mouse sobre el nombre del método y seleccionamos "Agregar Vista...":

El nombre de la vista la dejamos con el nombre propuesto "FormularioVisita", la plantilla debe ser
"Empty (sin modelo) y finalmente sacamos el Check del "Usar página de diseño" (para evitar que se
agreguen otros archivos que veremos más adelante y que hace más complejo el problema):

Si vemos ahora el "Explorador de soluciones" podemos observar que se ha creado un archivo

llamado "FormularioVisita.cshtml" en la carpeta "Views", subcarpeta "Home".

El contenido de este archivo lo modificamos para que muestre el formulario HTML que permita
ingresar el nombre de una persona y sus comentarios:

@{
Layout = null;
}

<!DOCTYPE html>

<html>
<head>
<meta name="viewport" content="width=device-width" />
<title>FormularioVisita</title>
</head>
<body>
<div>
<form method="post" action="/Home/CargaDatos" >
 <p>Nombre:<input type="text" name="nombre" /></p>
<p>Comentarios<br />
<textarea rows="10" cols="120"
name="comentarios"></textarea></p>
<p><input type="submit" value="Confirmar" /></p>
</form>
</div>
</body>
</html>

Hemos codificado un formulario HTML con un control "input" de tipo "text" y un control de tipo
"textarea". Además del botón de tipo "submit" que envía los datos al servidor.

La propiedad action del elemento form indica que URL de nuestro controlador debe atrapar el envío
de los datos del formulario que carga el operador:

<form method="post" action="/Home/CargaDatos" >

Significa que en el controlador HomeController debemos plantear un método llamado CargaDatos.

Si ejecutamos la aplicación veremos que podemos ver el formulario:

Pero cuando presionamos el botón de "Confirmar" nos muestra el error 404 que retorna el servidor:

4. Primero crearemos el modelo que tiene como responsabilidad almacenar los datos del visitante que
serán comunicados por el controlador.

Presionamos el botón derecho del mouse sobre la carpeta Models y seleccionamos la opción
"Agregar" -> "Clase...":

Creamos la clase "LibroVisitas.cs":

Codificamos la clase para permitir almacenar los datos en el archivo de texto:

using System;
 using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Hosting;
using System.IO;

namespace Proyecto4.Models
{
public class LibroVisitas
{
public void Grabar(string nombre, string comentarios)
{
StreamWriter archivo = new
StreamWriter(HostingEnvironment.MapPath("~") +
"/App_Data/datos.txt", true);
archivo.WriteLine("Nombre:" + nombre +
"<br>Comentarios:" + comentarios + "<hr>");
archivo.Close();
}

}
}

El método Grabar recibe dos string y dentro del mismo procedemos a crear un objeto de la clase
StreamWriter que se encuentra en el espacio de nombres System.IO (Debemos disponer el using
respectivo)

Al constructor de la clase StreamWriter le indicamos el path o camino donde se almacena el archivo

de texto llamado "datos.txt", utilizamos el método MapPath del objeto HostingEnvironment que nos
devuelve la ruta donde se almacena nuestro proyecto. Le concatenamos la carpeta "App_Data"
donde se debe almacenar el archivo de texto.
El segundo parámetro de MapPath al pasar un true indicamos que si ya existe el archivo lo abra para
añadir datos al final.

Mediante el método WriteLine procedemos a grabar en el archivo de texto los parámetros nombre y
comentarios.
Finalmente cerramos el archivo llamando al método Close.

5. Ahora crearemos otra acción en el archivo HomeController donde llamaremos al modelo para que
efectúe la carga de datos. Abrimos el archivo HomeController y codificamos:
6. using System;
7. using System.Collections.Generic;
8. using System.Linq;
9. using System.Web;
10. using System.Web.Mvc;
11. using Proyecto4.Models;
12.
13. namespace Proyecto4.Controllers
14. {
15. public class HomeController : Controller
16. {
17. // GET: Model
18. public ActionResult Index()
19. {
20. return View();
21. }
22.
23. public ActionResult FormularioVisita()
24. {
25. return View();
26. }
27.
28. public ActionResult CargaDatos()
29. {
30. string nombre =
Request.Form["nombre"].ToString();
31. string comentarios =
Request.Form["comentarios"].ToString();
32. LibroVisitas libro = new LibroVisitas();
33. libro.Grabar(nombre, comentarios);
34. return View();
35. }
36. }
37. }

La acción CargaDatos se ejecuta cuando el visitante confirma los datos del formulario de visitas.
Primero recuperamos los datos ingresados por el visitante en los dos controles HTML:
 string nombre = Request.Form["nombre"].ToString();
string comentarios = Request.Form["comentarios"].ToString();

Seguidamente creamos un objeto de la clase LibroVisitas y llamamos al método Grabar:

LibroVisitas libro = new LibroVisitas();

libro.Grabar(nombre, comentarios);

Esta es la forma que tiene el "Controlador" de comunicarse con el "Modelo", en este caso para pedir
que almacene los datos ingresados en el formulario.

Nos falta ahora crear una vista para la acción CargaDatos. Presionamos el botón derecho del mouse
sobre el nombre del método "CargaDatos()" y seleccionamos "Agregar vista", luego codificamos el
archivo CargaDatos.cshtml:

@{
Layout = null;
}

<!DOCTYPE html>

<html>
<head>
<meta name="viewport" content="width=device-width" />
<title>CargaDatos</title>
</head>
<body>
<div>
<p>Los datos ingresados fueron almacenados.</p>
<p>Gracias por sus comentarios.</p>
<p><a href="/">Retornar</a></p>
</div>
</body>
</html>

Podemos ahora seleccionar nuevamente el archivo Index.cshtml y ejecutar el proyecto. Cargamos

los datos en el formulario y presionamos el botón de Confirmar:
 El navegador muestra la vista, pero también en el servidor se almacenaron los datos cargados en el
formulario HTML. Si vemos la carpeta "App_Data" encontraremos que se ha creado el archivo
"datos.txt", que va creciendo a medida que se agregan comentarios.

38. Nos queda resolver la página que muestra todos los comentarios dejados por los visitantes.

Primero codificaremos la responsabilidad de leer el archivo de texto que le corresponde al "Modelo".

Abrimos el archivo "LibroVisitas.cs" y codificamos el método "Leer":

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Hosting;
using System.IO;

namespace Proyecto4.Models
{
public class LibroVisitas
{
public void Grabar(string nombre, string comentarios)
{
StreamWriter archivo = new
StreamWriter(HostingEnvironment.MapPath("~") +
"/App_Data/datos.txt", true);
archivo.WriteLine("Nombre:" + nombre +
"<br>Comentarios:" + comentarios + "<hr>");
archivo.Close();
}

public string Leer()

{
StreamReader archivo = new
StreamReader(HostingEnvironment.MapPath("~") +
"/App_Data/datos.txt");
string todo = archivo.ReadToEnd();
archivo.Close();
return todo;
}
 }
}

El método Leer procede a crear un objeto de la clase StreamReader e indicamos el path donde se
encuentra el archivo a leer llamado "datos.txt".
Midente el método "ReadToEnd" recuperamos todos los caracteres almacenados en el archivo de
texto y finalmente luego de cerrar el archivo procedemos a retornar un string con todos los caracteres
leidos.

Ahora debemos agregar en el "Controlador" un método que responda al segundo hiperínculo de la

página principal del sitio llamado "ListadoVisitas":

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using Proyecto4.Models;

namespace Proyecto4.Controllers
{
public class HomeController : Controller
{
// GET: Model
public ActionResult Index()
{
return View();
}

public ActionResult FormularioVisita()

{
return View();
}

public ActionResult CargaDatos()

{
string nombre =
Request.Form["nombre"].ToString();
 string comentarios =
Request.Form["comentarios"].ToString();
LibroVisitas libro = new LibroVisitas();
libro.Grabar(nombre, comentarios);
return View();
}

public ActionResult ListadoVisitas()

{
LibroVisitas libro = new LibroVisitas();
string todo = libro.Leer();
ViewData["libro"] = todo;
return View();
}
}
}

En el método ListadoVisitas procedemos a crear un objeto de la clase LibroVisitas y recuperamos el

contenido almacenado llamando al método Leer:

LibroVisitas libro = new LibroVisitas();

string todo = libro.Leer();

Mediante el diccionario ViewData podemos pasar datos a la vista, creamos una entrada en el
diccionario y le asignamos el string recuperado desde el "Modelo":

ViewData["libro"] = todo;
return View();

Paso siguiente debemos crear la "Vista" para el método "ListadoVisitas", para ello presionamos el
botón derecho del mouse y creamos la vista como hemos estado trabajando hasta ahora.

Modificamos el archivo "ListadoVisitas.cshtml" para que muestre todos los comentarios que se han
dejado en el sitio web:

@{
Layout = null;
}

<!DOCTYPE html>
 <html>
<head>
<meta name="viewport" content="width=device-width" />
<title>ListadoVisitas</title>
</head>
<body>
<div>
@Html.Raw(ViewData["libro"])
<br />
<a href="/">Retornar</a>
</div>
</body>
</html>

Ahora mediante Razor podemos recuperar los datos almacenados en el diccionario ViewData que
cargamos en el "Controlador", si bien podemos escribir:

<div>
@ViewData["libro"]
<br />
<a href="/">Retornar</a>
</div>

Luego como tenemos marcas HTML en el archivo de texto no aparecen correctamente. Debemos
utilizar el método Raw de HTML para su correcta visualización.
El resultado de esta vista es:

Ya tenemos correctamente funcionando nuestro pequeño sitio web que permite dejar comentarios y ver los
comentarios de otros visitantes. Todo esto utilizando el patrón del Modelo Vista Controlador.
Es necesario practicar para sentir más natural esta forma de organizar el código de nuestro proyecto en
distintas carpetas, con distintas clases que tienen asignadas distintas responsabilidades.