Ir al contenido principal

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.

Comentarios

Entradas más populares de este blog

Habilitar Usuario HR Oracle

Al realizar la primera instalación del Oracle, el usuario HR por defecto está bloqueado y por ende no podemos loguearnos como dicho usuario, lo que debe hacer son los siguiente pasos, aplicables para Linux o Windows.
1. Conectarse como usuario system o sysdba + contraseña haciendo uso del comando connect.
Usuario: system
Password: xxxx 


2. Hacer uso  del comando alter user hr account unlock desbloqueamos la cuenta.
alter user hr account unlock;

3. Escribimos el comando alter user HR identified by hr; con esto estamos diciendo que la contraseña será hr.

alter user HR identified by hr;

4. Ahora testeamos la conexión con el comando - conn hr/hr@xe. Si deseas después de conectarnos se puede realizar un select a la tabla employees del hr.


Resultado del select realizado
5. Con todos estos pasos realizados ya podemos logearnos desde cualquier IDE como el usuario hr  y la contraseña hr que definimos en el paso 3. 
Para finalizar nos loguearemos con el IDE Oracle SQL Developer.

Espero les sea de utilidad,…

Usuario SYS y SYSTEM - ORACLE

Usuario SYS y SYSTEM
Ambos usuario son creados de forma automática al crear la base de datos ORACLE y se otorga el rol de DBA.

SYS (password por defecto: CHANGE_ON_INSTALL).
SYSTEM (password por defecto: MANAGER).

Lo que se recomienda es cambiar el password de ambos usuarios por el tema de seguridad.

SYS:
Todas las tablas y vistas para el diccionario de datos de la base de datos están almacenados en el esquema SYS. Estas tablas y vistas son críticas para el funcionamiento de la base de datos ORACLE. Para mantener la integridad del diccionario de datos, las tablas del esquema SYS son manipulados solo por la base de datos. Nunca se debería modificar algo o crear tablas en el esquema del usuario SYS.

SYSTEM:
El usuario SYSTEM se utiliza para crear tablas y vistas adicionales que muestran información administrativa, tablas internas y vistas utilizado por varias opciones y herramientas de la base de datos ORACLE. No se recomienda utilizar el esquema SYSTEM para almacenar tablas de interés para usu…

Parámetro de entrada y salida – PL/SQL

Parámetro de entrada y salida – PL/SQL:
Los parámetros de entrada y salida no son los parámetros de inicialización de la base de datos ORACLE. Los parámetros de entra y salida son utilizados mayormente en implementaciones de funciones, procedimientos almacenados o bloques de código bajo el lenguaje del PL/SQL, se considera que ambos parámetros (entra y salida) puedan realizar operaciones en el mismo bloque PL/SQL, es decir, si enviamos un parámetro de entrada hará que cumpla cierta operación y retornara los valores de salida de dicha operación procesada de acuerdo al parámetro de ingresado. Es de acuerdo al caso que nos presenta en la implementación.
Algo importante al definir los parámetros, es saber y considerar cuántos tipos de parámetro existe si solo hablamos de entrada y salida, en realidad mi determinación seria 3 tipos:

Parámetros:

IN – entrada
OUT – salida
IN OUT – entrada salida

Parámetro IN – entrada:
El comportamiento común de estés tipos de parámetros es estar siempre pendiente d…