jueves, 31 de diciembre de 2015

Agregar controlador ASP.NET MVC - Fase III

Siguiendo con la fase de implementar nuestro proyecto, ahora implementaremos nuestro controlador y espero detallar algo sobre ello (más adelante profundizaré al respecto).

Controladores: La interacción del usuario con aplicaciones ASP.NET MVC, se organiza en torno a los controladores y Action Methods, es decir, se encargan de interactuar con el usuario. Considerando el punto de entrada de un Request HTTP cuando se trabaja con MVC que es el Controlador (Controller).

Con esta pequeña teoría quiero iniciar la parte practica de la implementar del controlador login y no se olviden de revisar Agrear modelo ASP.NET MVC - Fase II

1.  Clic derecho en el directorio Controllers, selecciionar Agregar y clic en controlador.

2.  Asigna nombre nombre de Login (la palabra Controller es una palabra reservada), el tipo de pantalla sera vacía y clic en aceptar.

     2.1. En nuestro controlador creado (clase) se importará el using PRO_SEGURIDAD.Models (contiene nuestro modelo login) y using PRO_SEGURIDAD.Repositorio (contiene nuestro métodos con acceso a datos). Y se implementará los siguientes métodos:

public LoginController(): Método para acceder a la clase interfaz de la conexión a datos.
public ActionResult Login(): La acción para elazar con la vista inicia, en nuestro caso es login (recuerda que nuestro archivo de configuración fue cambiada).
public ActionResult Login(Login login): La acción para control de la validación, acceso del login y redireccionar la vista según validación.
public string getRolIdUsuario(string UserId): Método para invocar al método getRolIdUsuario relacionado a la conexión a datos.

public string getIdUsuario(string UserName): Método para invocar al método getIdUsuario relacionado a la conexión a datos.
public class LoginController : Controller
    {
        ILoginData ObjILoginData;//Referencia a la interfaz para el acceso a datos

        public LoginController()
        {
            ObjILoginData = new LoginData();
        }

        [HttpGet]
        [AllowAnonymous]
        public ActionResult Login()
        {
            return View("Login");
        }

        [HttpPost]
        [AllowAnonymous]
        [ValidateAntiForgeryToken]
        public ActionResult Login(Login login)
        {
            if (ModelState.IsValid)
            {
                //Se capturan los valores de la base de datos
                var IdUsuario = getIdUsuario(login.usuario);
                var RolUsuario = getRolIdUsuario(Convert.ToString(IdUsuario));

                //Se controla si el usario esta asignado a un determinado rol
                if (string.IsNullOrEmpty(Convert.ToString(RolUsuario)))
                {
                    ModelState.AddModelError("Error", "El usuario no cuenta con un rol asignado");
                    return View(login);
                }
                else
                {
                    //Se inica las sesiones
                    Session["Usuario"] = login.usuario;
                    Session["IdUsuario"] = IdUsuario;
                    Session["RolAsigando"] = RolUsuario;

                    if (string.Equals(Convert.ToString(Session["RolAsigando"]), "Admin"))
                    {
                        return RedirectToAction("AdminDashboard", "Dashboard");//Si el rol asignado es Admin se redirecciona a la vista AdminDashboard
                    }
                    else
                    {
                        return RedirectToAction("UsuarioDashboard", "Dashboard");//Si el rol asignado es Usuario se redirecciona a la vista UsuarioDashboard
                    }
                    //A esto se puede adicinar mas roles, es decir n roles y se controla a base de un switch
                }
            }
            else
            {
                ModelState.AddModelError("Error", "Por favor, Ingresar nombre del usuario y password");
            }
            return View(login);

        }

        [NonAction]
        public string getRolIdUsuario(string UserId)
        {
            return ObjILoginData.getRolIdUsuario(UserId);
        }

        [NonAction]
        public string getIdUsuario(string UserName)
        {
            return ObjILoginData.getIdUsuario(UserName);
        }

    }

3.  Ahora creamos en controles Dashboard, al igual que el punto 1 y 2. Con la diferencia que esto solo contara con la acciones para las vista AdminDashboard() y UsuarioDashboard().
public class DashboardController : Controller
    {
        //
        // GET: /Dashboard/
        public ActionResult AdminDashboard()
        {
            return View();
        }

        public ActionResult UsuarioDashboard() {
            return View();
        }
    }

Espero les sirva y les recomiendo que revisen la segunda fase.

Agregar modelo ASP.NET MVC - Fase II

Bueno, inicio esta siguiente fase esperando que sea útil para todos ustedes y a esperar el año 2016 que sea de muchas bendiciones y éxitos en todo lo que nos espera. Para los que están interesado el como iniciar en crear un proyecto les dejo en siguiente link Crear Proyecto ASP.NET MVC - Fase I 

Ahora implementaremos el modelo, controlador y vistas (en diferentes fases), digamos estas 3 palabras son las que encapsula toda implementación cuando se realiza bajo este padrón denominado MVC. Esta claro que a lo largo iremos viendo algunos concepto esenciales en toda nuestra implementación.

Para esto vamos a conceptualizar y detallar algunos puntos sobre el Modelo.

Modelos: Es el conjunto de clases (entidades o tablas que estén asociados con el modelo de datos) que representan el dominio de la aplicación. Actualmente se puede realizar diferentes tipos de implementación, incluso usando ORM de terceros con el Dapper.Net, entre otros. Algunas implemntaciones más usadas hasta ahora son:
  1. Entity Framework Database First: Consiste en crear un modelo de clases a partir de una base de datos existente usando el diseñador del Visual Studio.
  2. Entity Framework Model First: Consiste en crear un modelo de clases usando el diseñador que es provisto por el Visual Studio y a partir de este se crea la base de datos.
  3. Entity FrameworkCode First: Consiste en hacer uso de solamente código para crear el modelo de clases, sin depender de una herramienta de diseño, y a partir de este se crea la base de datos.
  4. Y también esta el Data Access Application Block del Enterprise Library que toma mucha fuerza en estos últimos tiempos, espero profundizar más adelante.
Hay mucha teoría por plasmar, si hay tiempo espero plasmar muchísima más teórica - en lo personal es lo primordial para todo aprendizaje. Con este poquísima teoría quiero iniciar la parte practica.

Ah, el modulo que decidí implementar será acerca del control de acceso a usuarios, es decir usare como modelo la base de datos que en su momento hice publico en el siguiente articulo Modulo de Control de Acceso - Primera Fase, todo sera basado en este modelo, sería genial que le den una leída. Otro de los detalles a considerar es que utilizare como acceso a datos el ORM Dapper (de paso voy aprendiendo a usar este orm que es light, más adelante haremos algo con Entity FrameworkData Access Application Block del Enterprise Library) y algo de T-SQL (implementare algunos procedimientos almacenados)

1.  Iniciamos el modelo de la base de datos que se hará uso por ahora sólo serán las 3 primera entidades (tablas) para el acceso del login.

2.  Creamos 2 procedimientos almacenados:
     2.1. Para la captura del id del usuario a logearse


USE [BD_SISTEMA]
GO
/****** Object:  StoredProcedure [dbo].[SP_GET_IDUSUARIO]    Script Date: 12/31/2015 18:07:46 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[SP_GET_IDUSUARIO]
@PV_USUARIO VARCHAR(20)   
AS   
BEGIN
 SELECT ID_USUARIO
 FROM BD_SISTEMA.dbo.SEG_USUARIO
 WHERE USUARIO = @PV_USUARIO
END

     2.2. Para la captura de la descripción del rol a donde pertenece el id usuario.


USE [BD_SISTEMA]
GO
/****** Object:  StoredProcedure [dbo].[SP_GET_DES_ROL_IDUSUARIO]    Script Date: 12/31/2015 18:07:50 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[SP_GET_DES_ROL_IDUSUARIO] 
@PN_ID_USUARIO NUMERIC(8)
AS 
BEGIN
 SELECT R.DES_ROL FROM BD_SISTEMA.dbo.SEG_USUARIO_ROL UR
    INNER JOIN BD_SISTEMA.dbo.SEG_ROL R
 ON R.ID_ROL = UR.ID_ROL
 WHERE UR.ID_USUARIO = @PN_ID_USUARIO
END

Con estos 2 pasos iniciales pasaremos a implementar nuestra app mvc:

3.  Creamos nuestro modelo de nombre login, clic en el directorio model, agregar clase,


Definamos el nombre, por ahora solo estoy haciendo referencia a la entidad SEG_USUARIO y los campos usuario y password (por ahora).

Consideración: Para el uso de las anotaciones deben importar los el espacio de nombre using System.ComponentModel.DataAnnotations, casi en su mayoría de las implementaciones son frecuentes las anotaciones.

4.  Antes de continuar con la implementaciones de las calses, vamos a configurar el archivo de configuración, es decir en archivo Web.config de la raíz principal de nuestro proyecto (no confundir con el archivo que se genera internamente en el directorio Views) agregamos nuestra cadena de configuración.
<connectionstrings>
    <add connectionstring="Data Source=.;Database=BD_SISTEMA;UID=sa;Password=xxx" name="ConnectionBD" providername="System.Data.SqlClient">
    </add>
</connectionstrings>

4.1. Así mismo se hará el siguiente cambio - en la línea de autentificación loginUrl (es solo para que sea algo distinto y poder familiarizarnos con los controladores y acciones).
<authentication mode="Forms">
    <!--<forms loginUrl="~/Account/Login" timeout="2880"/>-->
    <forms loginurl="~/Login/Login" timeout="20">
    </forms>
</authentication>

5.  Ahora con la entidad creada, se creará un nuevo directorio de nombre Repositorio (contendrá las clases de conexión a datos), y se implementara las clases de acceso a datos.
Dentro del directorio se implementa la clase Login y su interfaz

    5.1. Como les menciones al inicio, para esta caso utilizare Dapper para la manipulación de datos, para esto haré uso de NuGet.
Clic en el menú Herramientas, seleccionar Administrador de paquetes de biblioteca y clic en Administrar paquetes NuGet para la solución


Realizar la búsqueda y clic en Instalar

En nuestro caso solo contamos con un solo proyecto, pero si hubiera mas proyecto tendríamos que seleccionar el proyecto donde se desea instalar y clic en Aceptar

Si la instalación se realizo correcto indicará el aspa y clic en cerrar el administrador de NuGet.

    5.2. Ahora con todo la instalación del dapper iniciamos la implementación de nuestra clase Login.cs. Importamos las librerías necesarias como el using System.Configuration (para la referencia a nuestra cadena de conexión), using PRO_SEGURIDAD.Models (para la referencia a nuestro modelo login - creado en el punto 3) y por ultimo el using Dapper la que acabos de instalar y los métodos a crear son:

getIdUsuario: Invoca al procedimiento almacenado  SP_GET_IDUSUARIO, es decir es el encargado de captura el id del usuario.
getRolIdUsuario: Invoca al procedimiento almacenado SP_GET_DES_ROL_IDUSUARIO, es decir es el encargado de captura la descripción del rol al que pertenece el usuario.
public string getRolIdUsuario(string UserId)
{
 using (SqlConnection con = new SqlConnection(ConfigurationManager.ConnectionStrings["ConnectionBD"].ToString()))
   {
         var dpara = new DynamicParameters();
         dpara.Add("@PN_ID_USUARIO", UserId);
   return con.Query("SP_GET_DES_ROL_IDUSUARIO", dpara, nulltrue, 0, CommandType.StoredProcedure).SingleOrDefault();
    }
}

public string getIdUsuario(string UserName)
{
 using (SqlConnection con = new SqlConnection(ConfigurationManager.ConnectionStrings["ConnectionBD"].ToString()))
     {
          var dpara = new DynamicParameters();
          dpara.Add("@PV_USUARIO", UserName);
   return con.Query("SP_GET_IDUSUARIO", dpara, nulltrue, 0, CommandType.StoredProcedure).SingleOrDefault();
     }
}

5.3. Para concluir creamos la clase ILogin.cs. con los 2 métodos creados:


public interface ILoginData
{
    string getRolIdUsuario(string UserId);
    string getIdUsuario(string UserName);
}

Para concluir con esta fase, quiero dejar en claro que el modelo no solo es detallar una clase que contempla tu modelo entidad, es decir no solo es el valor del campo de la entidad a la cual se hace referencia; influye en tipo de implementación a acceso a datos que en realidad es el punto de partida para toda implementación sea MVC, Web Forms, Web Page o un Single Pages entro otros, en lo personal la mejor decisión es busca la herramienta o tecnología adecuada y plantear alternativas que mas se adecuan a la organización segun sus necesidades y visiones que tiene con la aplicación a implementar, así que no importar si uses un ORM o ADO.Net o que a uno le guste, es que en realidad lo que interesa es la correcta decisión a tomar en toda implementación.

Bueno, espero que les guste esta fase. Nos vemos en la siguiente fase.

Saludos.

sábado, 26 de diciembre de 2015

Crear Proyecto ASP.NET MVC - Fase I

Quizás llamarlo proyecto desde un inicio a esta fase inicial es algo interesante, que a lo largo  espero   profundizar en diferentes fases la implementación de un pequeño proyecto - módulo. Por ahora nos conformaremos en crear un proyecto básico en MVC que sera el inicio de nuestro modulo. Para este caso haré uso de Visual Studio 2015 ultimate, también es aplicable con la edición express, Framework 4 y puedes descargarlo desde la pagina oficial de Microsofto y MVC 4. Sin mayor detalles, manos a la obra.

Iniciamos creando nuestro proyecto:

Seleccionamos la aplicación de tipo ASP.NET MVC 4:

Determinamos nombre y ubicación del proyecto

Seleccionamos el tipo de plantilla básico. Para conocer los tipos y detalles de cada una de las plantilla puedes revisar en siguiente link Plantillas, motor de vista y pruebas unitarias ASP.NET MVC.

Esperamos que carga todos los archivo necesarios al crear el proyecto.

Esto son los archivos y carpetas que nos crear la plantilla básica.

Esto son los archivos y carpetas que nos crear la plantilla básica.

Detalles de los archivos y carpetas generadas

Ahora crearemos un controlador 


Definimos el nombre del controlador 

Controlador creado

Ahora agregamos una vista, clic derecho en la vista creada de nombre index y clic en agregar vista.

Para este caso se mantendrá el mismo nombre index y el motor de vista será razor (si deseas conocer acerca de este tema puede visitar el siguiente link Plantillas, motor de vista y pruebas unitarias ASP.NET MVC). Además, se asociara la vista maestra _Layout.cshtml

Asociar vista maestra

Index creado

Revisando el código generado se vera el titulo del index y la vista maestra en <h2></h2> se agregara al palabra Hola Index. Con estos pasos ejecutamos presionando F5.

Sorpresa, sorpresa... este es el punto interesante de MVC, digamos que aquí se vera la magia de las convenciones, es decir se debe definir el controlador index + la acción index. Por defecto nos trae el controlador Home.

Realicemos los cambios necesario, compilamos y presiones F5 para volver a ejecuta.

Como Resultado de nuestra primera fase tendremos este siguiente resultado.
Espero les sirva, nos vemos en el siguiente articulo donde implementaremos nuestro proyecto que acabamos de crear y explicar paso a paso; además en este apartado explicamos el paso a paso para agregar un controlador y su respectiva vista.

Plantillas, motor de vista y pruebas unitarias ASP.NET MVC

Después de haber conceptualizado algunos punto importantes de ASP.Net MVC, quiero darles a conocer algunas de las bondades que nos presenta al momento de crear un proyecto -  como son los tipos de plantillas, el motor de vista y proyecto de pruebas unitaria (más adelante realizaremos un tipo de proyecto especifico de este tipo). 

En ASP.NET MVC como framework de app's (aplicaciones) web, debemos conocer la herramienta que nos permite utilizar todo su potencial, en este caso el Visual Studio, como IDE bastante extenso que debemos enfocarnos primeramente en las funcionalidades que nos permitan empezar a desarrollar nuestras aplicaciones. Es decir las Plantillas MVC es una de las herramientas de gran importancia al iniciar todo proyecto MVC.

Al elegir una de estas plantillas nuestro proyecto heredará algunas estructuras y archivos que nos sirven de base. Para poder elegir una plantilla, primero debemos crear un nuevo proyecto (mas adelante detallaremos como crear proyectos MVC), por ahora debemos hacer referencia a la ventana de Nuevo proyecto de ASP.NETMVC:


Tal como vemos en la sección de seleccionar un plantilla contamos con 6 tipos de plantillas disponibles, vamos a describir cada una de ellos para tener un entendimiento del escenario de nuestros proyectos que desea crear y aprovechar todo lo necesario y útil cuando decidamos utilizar una u otra implementación.

Vacía o Empty: Esta plantilla nos crea solo la estructura básica para tener el esqueleto de nuestra aplicación, es utilizada más que todo cuando ya sabemos que queremos y no necesitamos de los componentes que nos pueda generar Visual Studio; a pesar de ser básica esta plantilla incluye algunas librerías Javascript que nos pueden ser útiles.

Básica o Basic: Similar al enfoque anterior nos crea solamente la estructura de carpetas necesaria para levantar una aplicación con ASP.NET MVC, al ser tan básica esta plantilla, requiere que creemos todo lo que vayamos a utilizar prácticamente desde cero. En lo personal me gusta usar esta plantillar porque puedo definir mi propia estructura del proyecto.

Aplicación de Internet o Internet Application: Inicia donde había quedado la plantilla vacía, contiene todo lo necesario visto en la mencionada plantilla vacía, sin embargo nos incluye un controlador inicial por defecto que nos lleva al home de la aplicación y adicionalmente nos crea un AccountController, es decir, un controlador para manejar todo lo concerniente a registro de usuarios y manejo de sesiones.

Aplicación de Intranet o Intranet Application: Funciona muy similar a la Aplicación de Internet, solamente que difiere en que está configurada para utilizar la autenticación basada en Windows, que es más deseable cuando trabajamos entornos de Intranet.

Aplicación Móvil o Mobile Application: Es otra variación de la aplicación de Internet que nos ofrece, sin embargo esta plantilla nos trae el framework de Javascript Jquery Mobile, que es enfocado a plataformas móviles como celulares y tablets, adicionalmente las vistas vienen optimizadas para ser mostradas en dispositivos móviles.

Web API: Como su nombre lo indica esta plantilla viene especializada para crear APIs RESTful, es decir podemos generar rápidamente servicios Web para alimentar otras aplicaciones que necesitemos comunicar con nuestra estructura.

Los Motores de vistaen MVC son los responsables del renderizar el HTML de las vistas. Por defecto el framework MVC incluye dos motores: ASPX (WebForms) y Razor, pero no quiere decir que son lo único  existen hay muchos más como Spark, NHaml o Bellevue (por mencionar algunos - espero revisarlo en su debido momento) que podemos mencionar a colección de view engines - Motores de vista de nuestro proyecto.

Se considera cuando devolvemos un objeto ViewResult en una acción de un controlador, por ejemplo a través del método View, el framework itera sobre los motores de vista registrados y por cada uno de ellos intenta localizar la plantilla que corresponde con el nombre solicitado. El primer view engine que lo encuentre será el motor que renderizará la vista, dejando de iterar sobre los restantes.

Así mismo, cada motor de vistas tiene su propia lógica para buscar las plantillas, normalmente lo hacen a través del sistema de archivos, es decir, por ubicación física. Los motores WebForms (.aspx, .ascx) y Razor (.cshtml, .vbhtml) implementados en las clases WebFormViewEngine y RazorViewEngine respectivamente, buscan las plantillas por ubicación. Quiere decir concretamente buscan el nombre de la plantilla con un determinado nombre de extensión en diferentes directorios.

Si ejecutamos una acción de un controlador haciendo referencia a una vista que no existe, recibiremos como respuesta el error que no se encuentra la vista o no hay un motor de búsqueda (en el siguiente apartado detallaremos más a fondo).

Los Proyecto de pruebas unitarias, quizás sea una de las ventajas de mucha importancia que brinda el uso de ASP.NET MVC. Es decir se puede implementar fácilmente pruebas unitarias en la aplicación web. Esto resulta especialmente cierto en comparación con el modelo de páginas de formularios Web Forms de ASP.NET, donde las pruebas unitarias son más complejas y tediosas, porque es difícil aislar una funcionalidad específica y porque las pruebas de las páginas de formularios Web Forms requieren la invocación del servidor web y la ejecución de la canalización de las páginas completas. ASP.NET MVC se ha diseñado para poder realizar pruebas sin dependencias del servidor IIS, de una base de datos o de clases externas, un gran punto a favor los que lo hacen (bueno, hasta ahora no lo uso mucho que digamos, solo como para ejemplos pequeños).

En fin, con esto pretendo familiarizar un poco con el tema de las herramientas que nos ofrece el IDE de VIsual Studio enfocado en ASP.Net MVC, espero lo aprovechen.

Saludos, nos vemos en el siguiente articulo.

Iniciando ASP.Net MVC

Quiero iniciar este articulo haciéndoles mención que hace más de un año atrás lo tenia planeado, es decir cuando estuve aprendiendo MVC. Así que aprovecho el tiempo libre que por ahora tengo en estas fechas festivas. Claro está que quiero iniciar con un poco de concepto y luego entramos a la práctica con algunos ejemplos sencillos hasta realizar algún pequeño modulo que se me ocurra más adelante.


Iniciamos con la gran pregunta, que es ASP.Net MVC:

Lo que se debe tener claro desde un principio es que ASP.NET MVC está construido usando ASP.NET, es decir todos los aspectos transversales de ASP.NET (como la autenticación, cache, sesión, roles) siguen siendo los mismos en ASP.NET MVC.

MVC básicamente de lo que se encarga es separa la lógica del modelo (datos) de una aplicación de la lógica de presentación y la lógica empresarial. En ASP.NET MVC, esta separación lógica se implementa también físicamente en la estructura del proyecto, donde los controladores y las vistas se guardan en carpetas que usan convenciones de nomenclatura para definir las relaciones. Esta estructura es compatible con las necesidades de la mayoría de las aplicaciones web.

Remplaza ASP.Net MVC a ASP.Net?

Otro de los conceptos que tenemos se debe tener claro es que ASP.NET MVC forma parte del marco de trabajo ASP.NET, es decir el desarrollar una aplicación ASP.NET MVC es una alternativa al desarrollo de páginas de formularios Web Forms de ASP.NET (quiere decir no reemplaza el modelo de formularios Web Forms).

Lo que hay que tener en claro es que Microsoft ya ha anunciado que ambos frameworks (ASP.NET MVC y Webforms) se seguirán evolucionando. Así que no esta de más dominar ambos frameworks, quizás lo que puede remplazar o sustituir en ASP.NET MVC son las páginas .aspx por la .cshtml  es decir la invocación de los controladores.

Diferencia entre páginas .aspx y .cshtml:

En realidad la única diferencia esta en la existen de dos motores principales para implementar las vistas, uno de ellos es el típico y el de siempre ASP.Net y el nuevo motor de MVC llamado Razor.

Es decir la principal diferencia está en el motor que usamos a la hora de la implementación, los archivos o famosas paginas con extensión .aspx se usan para crear la vista con códigos ASP.Net, mientras que los .cshtml son los archivos que se usan para renderizar código Razor. Otras de las consideraciones que hay que tener al implementar en MVC esta las MasterPages se ahora en MVC se le conoce como _Layout.cshtml es la página maestra "por defecto" que nos trae el MVC, considerando que todas las páginas se dirigen automáticamente a ella; si se desea NO HACER uso de la páginas maestras u otro archivo diferente al _Layout para una vista, se deberá escribir explicitamente el siguiente código al inicio de la página, es decir al _ViewStart.cshtml:


@{
    Layout = null; // si no se desea una masterpage
    Layout = "~/Views/Shared/_Layout.cshtml";// Por defecto para un diferente archivo
}

Haciendo eco del tan mencionado Patrón Modelo - Vista - Controlador (MVC):

Con todo lo detallado, quiero hacer mención que básicamente ASP.NET MVC es la implementación del patrón Modelo - Vista - Controlador (MVC) es decir para tecnología ASP.NET. El patrón MVC no es algo novedoso ya que en los finales de los años 70 se inicio la implementación en Smalltalk-80 que hacia mención de objetos metafóricamente - bueno en realidad esto ya no viene mucho al caso.

Brevemente podemos decir que el patrón MVC separa la lógica (acceso a datos) de una aplicación de su presentación, usando 3 componentes:

  1. Modelo: Representa las reglas de negocio de la aplicación (y el acceso a datos subyacente). Es decir invocar un objeto de manera camuflada o oculta por ser parte de la lógica de negocio.
  2. Vistas: Representan la presentación de la aplicación. Quiere decir es la visual con la cual interactúa el usuario final.
  3. Controlador: Actúan de intermediario entre el usuario y el Modelo y las Vistas. Es el encargado de recoger las peticiones del usuario, para la interacción con el modelo y decide que vista es la que debe mostrar los datos.
En contexto más generales de ASP.NET MVC se puede decir que:
  • Esta claro que toda la lógica de negocio y el acceso a datos es el Modelo (en muchos casos el Modelo puede estar en uno o varios emsanblados y referenciados).
  • Las vistas contienen, básicamente, el código que se envía al navegador, es decir el código HTML (código de servidor asociado, siempre y cuando este código haga cosas de presentación, no de lógica de negocio).
  • Los controladores reciben las peticiones del navegador y en base a esas, deciden que vista debe enviarse de vuelta al navegador y con qué datos.
Uno de los puntos de gran importancia a mi parecer es sobre las convenciones y configuraciones:

Se habla poco acerca de este punto de las convenciones, siempre el rodeo esta en el Modelo - Vista - Controlado. Pero la importancia de implementar el MVC sin saber el que es una convención y para que sirve es algo incompleto dicha info, así que intentare dejar un poco de este concepto.

En la estructura de un un proyecto MVC se conoce a la convención que es colocar los controllers en la carpeta llamada Controllers, carpeta que se crea de forma automático junto con el proyecto.

Es decir es está la magia de ASP.NET MVC?
El cómo se comunican todas las partes para desarrollarse juntas? La respuesta sencilla es, SÍ: Es decir si sigues las convenciones, el Framework MVC de ASP.NET sabrá que hacer sin que tengas que decírselo.

Ejemplo:
MVC utiliza una convención basada en el nombres de los directorios de la estructura para saber cuál vista debe usar. Esta convención nos permite omitir la ruta de ubicación de la vista  dentro de una clase Controladora. De forma predeterminada, ASP.NET MVC busca la vista en la ruta: Views \ \ [NombreControlador] \ \ [NombreMetodo].

Siendo más concreto, cuando en HomeController (por defecto usaré el IndexController en este ejemplo), dentro de un método (digamos Index() por ejemplo) retornamos:


public ActionResult Index()
{
    return View();

}

Y en nuestro archivo de RouteConfig.cs (se detallara de manera mas profunda en los siguientes post) se debe hacer referencia al controlador + la acción es decir de la siguiente manera:


public static void RegisterRoutes(RouteCollection routes)
{
     routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
     routes.MapRoute(
        name: "Default",
        url: "{controller}/{action}/{id}",
        //defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional}
        defaults: new { controller = "Index", action = "Index", id = UrlParameter.Optional}
     );
}

Es decir estamos indicándole al controlador que busque en: Views/Index/Index.cshtml - lo importante es saber cómo la convención permite saber qué vista mostrar sin tener que decirle la ubicación.

Para finalizar quiero hacer mención de las ventajas de ASP.Net MVC:

Es la gran facilidad con la que se generan URL semánticas, es decir URL que tengan la forma http://servidor/ver/almacen/productos en lugar de http://servidor/almacen/ver.aspx?code=productos. Las URLs semánticas se indexan mejor en los buscadores y son una práctica SEO habitual. Quiere decir que en webforms no se puedan hacer, es que en ASP.NET MVC vienen de serie.

A nivel técnico, es que ASP.NET MVC se facilita mucho el probar nuestra aplicación (especialmente usando pruebas unitarias). Otras de las ventajas es que el uso correcto del patrón MVC facilita la reutilización de código de manera mucho más efectiva que en webforms.

Por supuesto, como todo tiene un precio: la curva de aprendizaje de ASP.NET MVC puede ser más alta que la de webforms, especialmente si nunca hemos desarrollado para web. A diferencia de webforms, que te abstrae de HTTP y HTML. ASP.NET MVC está mucho más cerca de la web, lo que hace necesario conocer HTTP, HTML y Javascript para trabajar con él. 

Quiere decir si necesitamos crear aplicaciones web es normal que debas conocer los protocolos y lenguajes en los que se asenta la web.

Este artículo ha sido el inicio esperado de casi más de un año que quise impartir mi conocimiento en el mundo de ASP.NET MVC. Las versiones que iré detallando será en la versión 4 específicamente pero en otros artículos iré mostrando las bondades de manera práctica que a estas alturas ya hice algunas implementaciones con la versión 5. Sugerencia y comentarios son bienvenidos. 

Saludos, nos vemos en el siguiente articulo - espero lo haya pasado y disfrutado de una bonita navidad.