Configuración del Formato de Fechas en SQL SERVER

 

Aunque lo ideal es encapsular las variables de fecha en parámetros ya formateados en ocasiones (sobretodo en proyectos viejos) te encuentras con algunas consultas con las fechas directamente en string como el típico:

SELECT * FROM Pedidos WHERE FechaPedido >= '30/01/2011'

Es posible que esta consulta funcione correctamente en tu servidor de SQL SERVER local pero al llevarlo a producción te encuentres en ocasiones con el típico error:

La conversión del tipo de datos varchar en datetime produjo un valor fuera de intervalo / The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.

Este error ocurre cuando el servidor intenta comparar una columna con formato “DateTime” (como es el campo “FechaPedido” de nuestro ejemplo) con un String pasado como parámetro y, al intentar convertirlo se desborda.

¿Por qué ocurre esto? Porque el idioma del servidor le indica que debe interpretar las fechas de otro modo y al convertir el String en Date da un valor incorrecto (lo más clásico es que lo intente convertir en MM/DD/YYYY y como el mes 30 no existe pasa lo que pasa…).

 

Hay varias formas de solucionar este problema aunque, como he dicho al principio del post, lo ideal es pasar la fecha en una variable ya formateada como Date usando tecnologías de acceso a datos como Entity Framework, Linq o con los DataSets de ADO.NET.

 

Como SysAdmin: Modificar la configuración global de idioma del servidor

Si queremos modificar el idioma predeterminado de TODO el servidor para TODAS las bases de datos podemos hacer los siguiente:

Como “sa” y contra “master” ejecutamos lo siguiente:

SP_CONFIGURE 'default language', 5

RECONFIGURE;

Dónde el 5 pasado como parámetro es el idioma “Español” con formato de fecha “dd/mm/yyyy”.

Si queremos establecer otro idioma y no sabemos su identificador usad esta consulta:

USE master
SELECT * FROM syslanguages

De este modo todo nuevo login contra el servidor de base de datos usará este idioma por defecto y afectará a toda conversión de fecha que se solicite (como en la SELECT del ejemplo, un DATEDIFF o un DATENAME para obtener el nombre del día o mes).

 

Como SysAdmin: Modificar la configuración de idioma de un login en concreto

Si no queremos cambiar la configuración de idioma de todo el servidor (cosa lógica si hay otras bases de datos funcionando y no queremos modificar su comportamiento) podemos modificar sólo la configuración de idioma de un login en concreto para que cualquier consulta contra cualquier base de datos que lance dicho login utilice el idioma indicado.

La consulta para cambiar el idioma de un login es:

EXEC sp_defaultlanguage 'nombre del login', 'idioma'

Dónde “idioma” es el nombre del idioma que queremos establecer que podemos obtener del campo “name” de la tabla “master.syslanguages” tal y cómo hemos explicado antes.

 

Al igual que con el otro método es necesario que el usuario vuelva a reconectarse para hacer uso de la nueva configuración.

 

Como desarrollador: Establecer el idioma antes de hacer una consulta

Si no tienes más remedio que hacer una consulta pasando fechas como string puedes asegurarte de escoger el formato antes de realizar la consulta. Para ello basta con añadir la siguiente clausula ANTES de hacer la consulta:

SET LANGUAGE 'idioma'

Con lo que podríamos hacer que nuestra consulta de ejemplo funcione siempre en cualquier servidor sea cual sea el idioma del mismo haciendo la consulta así:

SET LANGUAGE 'español';

SELECT * FROM Pedidos WHERE FechaPedido >= '30/01/2011';

De este modo nos aseguramos que la conversión de la fecha siempre sea con formato del idioma “español” que es dd/mm/yyyy

 

Depende del escenario que tengas deberás usar un método u otro aunque, lo siento por repetirme, lo mejor es controlar el formato de la fecha a nivel de aplicación y no ir modificando la configuración del servidor.

 

 

Nos vemos compilando!!

WCF: Auditar errores a nivel de servidor


Windows Comunication Foundation (WCF) fue la evolución lógica de los antiguos Web Services de .NET 2.0 dotando a estos de multiples mejoras.

Aunque hoy en día se ha convertido en el estandar de uso para el desarrollo de servicios webs centralizados en .NET hay algunas cosas que Microsoft no terminó de pulir o complicó más de la cuenta.

Una de ellas es la captura de excepciones que ocurran en el servidor que aloja el WCF cuando es invocado desde un cliente en concreto y en este pequeño artículo vamos a explicar como configurar el servicio WCF para que audite los errores ocurridos.

 

Las típicas excepciones a nivel de cliente como “An unsecured or incorrectly fault error” o “An error occurred when verifying security for the message” realmente esconden el verdadero motivo del error y el único modo de saberlo es indicarle al servicio WCF que inserte en el Visor de Sucesos de Windows los detalles de la excepción usando “Service Security Audit“.

Para ello necesitaremos modificar el Web.Config añadiendo en el tag <behavior> el tag <serviceSecurityAudit> como en el ejemplo:

<behaviors>
      <serviceBehaviors>
        <behavior name="ServiceBehavior">
<serviceSecurityAudit auditLogLocation="Application" serviceAuthorizationAuditLevel="Failure" messageAuthenticationAuditLevel="Failure" suppressAuditFailure="true"/>
        </behavior>
      </serviceBehaviors>     
    </behaviors>

Los parámetros de “serviceSecurityAudit” son:

  • auditLogLocation:
    • Define dónde se almacenará el log del WCF.
    • Tipos:
      • Default
        • Los eventos se escriben en el Visor de Sucesos.
      • Application
        • Los eventos se escriben en el Visor de Sucesos de “Application”
      • Security
        • Los eventos se escriben en el Visor de Suscesos de “Security”
  • serviceAuthorizationAuditLevel y messageAuthenticationAuditLevel
    • Indica si se van a auditar los eventos de autorización y autenticación respectivamente contra el WCF.
    • Tipos:
      • None
        • No se almacena nada.
      • Success
        • Sólo las peticiones exitosas.
      • Failure
        • Sólo los errores.
      • SuccessAndFailure
        • Se almacena todo.
  • suppressAuditFailure
    • Valor booleano que indica si se ignoran o no las posibles excepciones que ocurran al intentar escribir en el log (la típica excepción guardando la excepción). Por defecto si se falla al intentar guardar la excepción esta es capturada e ignorada.
 
Si, como en mi caso, queremos saber solo cuando falla basta con que pongamos los valores a “Failure” y tendremos una entrada en el Event Viewer de nuestro servidor con el texto completo y real de la excepción.

 

IMPORTANTE: Activar el Service Security Audit reduce considerablemente el rendimiento del servicio WCF. Mi recomendación es que se desactive si ya has resuelto el error o si no necesitas auditar nada más.

 

Espero que este pequeño tutorial os ayude a encontrar esos horribles errores ocultos en vuestros servicios WCF.

 

Nos vemos Compilando!!

HTML5: SEO y Web Semántica

 

El pasado miércoles 22 de Junio 2011 tuve el placer de asistir a un taller introductorio de HTML5 y CSS3 impartido por Miguel Jiménez en el Aula Vulcan de los amigos de DotNetMania en Madrid.

 

Este pequeño curso tenía el objetivo de mostrar las novedades de HTML5 y CSS3 desde un punto de vista práctico haciendo hincapie en las características y ventajas frente al ya obsoleto modelo de web actual.

 

 

En futuros post iré expicando por encima las principales características de este nuevo lenguaje así que hoy empezamos por uno de los aspectos que me parecieron más importantes: Facilidad para crear una buena Web Semántica.

Una Web Semántica no es más que una página web cuyo código html es facilmente legible y entendible por robots, buscadores y lectores de web. 

Actualmente no se presta mucha atención a este aspecto a menos que tu web tenga que pasar los controles de accesibilidad para ciegos o tenga una alta importancia a nivel de indexación en buscadores. Y es que actualmente la estructura de nuestro código html es caótica, sin relación entre cada elemento y, lo que es peor, desestandarizada ya que cada uno pone lo que quiere.

¿Cómo puede un buscador saber, por ejemplo, qué parte de tu código html es el menú principal o la cabecera? La respuesta es simple: No puede.

Os pongo un ejemplo de una página típica con una cabecera, un menú superior de navegación, un cuerpo, lateral y pie de página. Si somos un poco ordenados podríamos tener una estructura como esta:

<div class="main"> 
 <div class="cabecera"></div> 
 <div class="menu"></div> 
   <div class="cuerpo"> 
       <div class="seccion"></div> 
   </div> 
 <div class="lateral"></div> 
 <div class="pie"></div> 
</div>

Cómo veis tenemos una serie de div para crear nuestros controles y cada uno con su clase css asignada dónde indicamos el tamaño, la posicón, etc… 

Este código a simple vista parece ordenado y se sabe cada div a qué parte de la web corresponde, ¿no? Bueno, a tus ojos si que puede parecerlo pero para un buscador o para un lector de web para ciegos un div con una clase “menu” es lo mismo que “cabecera” o “estilo1”, ¿cómo se supone que debe saber Google dónde está nuestro menú principal así?

Esto es lo que HTML5 resuelve con el uso de etiquetas semánticas para identificar cada uno de estos elementos de forma única e inequívoca: header, nav, article, section, aside y footer (entre otros).

Estos nuevos elementos se muestran en tu navegador como un div con la salvedad de que, al tener un nombre único, los lectores automáticos son capaces de entender que contiene y para que sirven cosa que hasta ahora era imposible.

  • <header> es la etiqueta utilizada para albergar los elementos que forman la cabecera de nuestra web. Tomando como ejemplo esta misma web sería el título “Compilando.ES”, subtítulo y fondo azul de la parte superior.
  • <nav> representa el contenedor de nuestro menú de navegación. Es de vital importancia resaltar este contenedor para que Google pueda generar los enlaces automáticos que aparecen debajo de tu web al buscarla. Por ejemplo:

  • <article> representa un elemento independiente y con sentido propio dentro de la web. El ejemplo es claro, cada post de este blog debería estar embebido en una etiqueta <article>.
  • <section> define una sección dentro del contenedor en el que se anida. Por ejemplo, una <section> en un post de este blog sería el listado de tags al pie.
  • <aside> representa la información que no está directamente relacionada con el resto de la web como la barra lateral con el blogroll o una banner de publicidad.
  • <footer> es el contenedor que alberga los elementos del pie de la página.

 

En nuestro ejemplo usando estas nuevas etiquetas semánticas de HTML5 la cosa quedaría así:

 

<body>
  <header></header>
  <nav></nav>
  <article>
    <section></section>
  </article>
  <aside></aside>
  <footer></footer>
</body>

 

Como veis el código queda más simple y entendible, no solo por ojos humanos si no por los buscadores que ahora ya sabrán dónde buscar los links o que parte de la web corresponde al texto o cabecera.

Además, al tener cada etiqueta un identificador único el estilo CSS se simplifica ya que basta con sobreescribir el estilo del “header” para dar formato a la cabecera sin tener que asignarle una clase con un nombre inventado por nosotros.

 

Espero que el ejemplo haya quedado claro y veais que es muy sencillo cambiar la vieja y desestructurada metodología de divs por esta nueva estructura semántica de HTML5.

Este es el primer artículo de la serie que estoy preparando y espero que os haya resultado últi. Como siempre cualquier duda comentario lo podeis escribir directamente en los comentarios del post.

 

¡¡Nos vemos Compilando!!

Code Snippet: LastIndexOf en SQL SERVER

Uno de los mótivos que me impulsó a abrir el blog es para usarlo también como “bloc de notas” e ir anotando pequeños apuntes de código que me han parecido interesanto o que me han resulto un problema. 

Estrenamos esta categoría llamada “Code Snippet” con una pequeña consulta en T-SQL para SQL SERVER que sirve para obtener la última aparación de un caracter en concreto en un string; vamos, lo que ha hecho toda la vida el método LastIndexOf() de .NET pero que SQL no incluye por defecto.

 

 

LEN(STRING) - CHARINDEX('CHAR TO SEARCH', REVERSE(STRING)) + 1

 

 

Básicamente le doy la vuelta al string y obtengo la primera aparición del caracter a buscar.

Un ejemplo de uso para buscar, por ejemplo, la posición de última “/” en un string sería así:

 

SELECT LEN('C:/Dir/File.txt') - CHARINDEX('/', REVERSE('C:/Dir/File.txt')) + 1;

 

Esta consulta devolvería “11”. Si queremos quedarnos con lo que hay después (como ha sido mi caso, que necesitaba el “File.txt”), la consulta quedaría así:

 

SELECT RIGHT('C:/Dir/File.txt', CHARINDEX('/', REVERSE('C:/Dir/File.txt')) - 1);

 

Espero que os sea de ayuda.

 

Nos vemos Compilando!!

Arquitectura MVC, ¿como puede mejorar mi aplicación?

Y es que ultimamente hemos oido mucho hablar sobre MVC pero, ¿qué es realmente y para que se usa? Empecemos desde el principio:

 

MVC son las siglas de Model-View-Controller (Modelo-Vista-Controlador) y es un patrón de la arquitectura del software descrito en 1979 por el Noruego Trygve Reenskaug.

 

El punto principal de MVC es dividir la aplicación en tres capas reales, una para datos, otra para la lógica y otra para la presentación consiguiendo que sea mantenible, escalable y reutilizable.

Para explicar en qué consiste y como funciona vamos a utilizar como ejemplo una hipotética aplicación web .NET que accede a una base de datos SQL SERVER a la que aplicamos este patrón.

  • El “Modelo“, o capa de datos, es el conjunto de clases que representan la información con la que vamos a trabajar y su lógica de negocio. En nuestro ejemplo serían las clases en las que consultamos a la base de datos SQL SERVER mediante, por ejemplo. modelos de Entity Framework.
  • La “Vista“, o capa de presentación, define el modo en el que el usuario ve los datos y como interactúa con ellos. Una página HTML con formularios sería un ejemplo claro de este tipo de capa.
  • El “Controlador“, o capa de lógica, es la que gestiona las peticiones de la Vista solicitando los datos necesarios al Modelo y adaptándolos para su correcta visualización. En .NET serían métodos que actuan como respuesta a un POST de un formulario HTML, captura los datos que el usuario ha introducido y solicita lo necesario al Modelo para retroalimentar la Vista.

 

 

Para terminar de explicar el funcionamiento vamos a platear un formulario de Login en nuestra web de ejemplo.

La Vista sería la página HTML con un <form> con dos <input> uno para el usuario y otro para la contraseña.

Al hacer submit del formulario la petición iría al Controlador que recupera esos datos y solicita al Modelo que busque si el usuario/contraseña introducidos son válidos.

El Modelo realiza la consulta a base de datos y le devuelve el resultado al Controlador que es el que determina si el intento de Login ha sido correcto o no. En caso de ser correcto iniciamos sesión en el sistema y redirijimos a una página de incio del usuario (por ejemplo), en caso de ser erroneo volvemos a la misma vista pero indicando un mensaje de error y el sistema vuelve al punto inicial en el que se espera una acción por parte del usuario.

 

Ventajas de usar MVC

 

  • Escalabilidad

La principal ventaja de separar la aplicación en tres capas reales es la escalabilidad.

Un par de ejemplos: bastaría con recargar el modelo si añades o editas una tabla o crear una nueva vista si quieres hacer una versión para navegador de dispositivo móvil.

  • Simplicidad

Otra gran ventaja es la simplicidad con la que se puede gestionar y mantener el sistema así como la posibilidad de trabajar en paralelo. Puedes tener a diseñadores trabajando en las vistas mientras que los desarrolladores se pueden centrar en el Controlador y el Modelo. ¿Qué quieres cambiar el diseño de la web? Tan solo edita el HTML y la aplicación seguirá funcionando.

  • Desarollo mediante TDD

Al tener la lógica separada de la interfaz es mucho más sencillo crear las pruebas unitarias y desarrollar mediante TDD (Test Driven Development). Sobre esto último dedicaré un artículo más adelante.

  • Rapidez y limpieza de código.

No hay ViewState, ni HTML autogenerado por controles, ni mantenimiento de estado en el código. Lo que interpreta el navegador es exactamente lo que hemos escrito. Eso hace que la página sea más ligera y cargue en menos tiempo.

  • Facilidad para el uso de jQuery

Al tener en la Vista código HTML directamente podemos integrar controles jQuery de forma más sencilla que en WebForms.

 

Conclusiones: ¿WebForms o MVC?

Como habeis podido comprobar en este punto las ventajas de usar este patrón son muchas pero no es oro todo lo que reluce.

MVC es una arquitectura muy compleja que requiere una abstracción mayor por parte del desarrollador que hace que el desarrollo sea más lento por eso solo es recomendable usarlo en ciertos tipos de proyectos.

Si lo que necesitas es hacer un prototipo o RAD, entonces utiliza WebForms.

Si necesitas que la página almacene datos y no quieres estar continuamente haciendo peticiones a la capa de persistencia, entonces utiliza WebForms.

Si tu equipo de desarrollo es pequeño y no trabajais con TDD, entonces utiliza WebForms.

 

En cambio, si tu equipo está segmentado en Diseñadores y Desarrolladores, dispones de conocimientos avanzados de JavaScript y Ajax y necesitas tener un control total del código generado MVC es el patrón que debes utilizar. Si además es un proyecto de cierta embergadura, necesitais controlar mediante pruebas unitarias y va cambiando/ampliandose de forma constante MVC es la solución.

 

Nos vemos Compilando!!

Uso de App.Config en aplicaciones de consola o Win Forms en .NET

Es muy común en nuestras aplicaciones el tener que extraer ciertas variables de configuración a un fichero externo para que se puedan modificar sin necesidad de volver a publicar la aplicación (como por ejemplo rutas que varían en función del servidor en el que publicas la aplicación, cuentas de correo para envíos que pueden cambiar su contraseña, cadenas de conexión, etc…)

En web ya tenemos el famoso Web.Config y su uso es bastante común para cualquier desarrollador web por lo que nos vamos a centrar en este sencillo artículo a cómo añadir un fichero de configuración a una aplicación de escritorio, escribirlo, leerlo y posteriormente modificarlo desde el bloc de notas.

 

Crear el fichero de configuración

Lo primero que debemos hacer es agregar el fichero de configuración a nuestra solución. Para ello nos vamos al explorador de soluciones de nuestro Visual Studio > Botón Derecho > Add > New Item > Application Configuration File.

 

 

Se añadirá un fichero XML con una estructura similar a la del Web.Config en el que podremos ir añadiendo las variables que queramos extraer añadiendo entradas al tag “appSettings” como el ejemplo siguiente:

 

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="mailEnvio" value="info@compilando.es"/>
    <add key="servidorEnvio" value="mail.compilando.es"/>
  </appSettings>
</configuration>

 

 

Leer el fichero de configuración desde la apliación

Una vez creado el fichero de configuración y añadidas las variables de configuración que queramos basta con hacer uso de la clase ConfigurationManager para leer el valor de las misma desde el código de nuestra aplicación:

 

 

string mailEnvio = ConfigurationManager.AppSettings["mailEnvio"];

 

 

Recuerda que has de utilizar el espacio de nombres “System.Configuration” (si no te aparece la clase es porque te falta añadir la dll al proyecto. Vete a Referencias > Añadir Referencia y en la pestaña de .NET busca System.Configuration y añadela al proyecto).

 

Publicar y Modificar la configuración del fichero desde fuera del Visual Studio

Una vez terminada y publicada nuestra aplicación (para este caso la llamaremos “Ejemplo”) tendremos el fichero ejecutable “Ejemplo.exe” que será el que arranque nuestra aplicación de consola o Win Forms y, junto a él, tendremos otro fichero llamado “Ejemplo.exe.config”

Este fichero es el fichero de configuración de la aplicación y se puede abrir perfectamente con el Bloc de Notas y editar los valores del XML para cambiar las variables de configuración si necesitar de recompilar la aplicación.

Así, en este ejemplo, podríamos cambiar el mail desde el que nuestra aplicación envío tan solo editando este fichero sin necesidad de abrir el Visual Studio lo que nos da una flexibilidad mayor a la hora de publicar y distribuir nuestra aplicaciones de escritorio.

 

Nos vemos Compilando!!

Gestión de Errores en ASP .NET: customErrors y Error Handling en Global.Asax

Uno de los aspectos más importantes a tener en cuenta cuando se pasa a producción una aplicación es como vas a tratar los posibles errores que ocurran en ella.

Por defecto, si no modificamos nada y ocurre un error sin controlar, la aplicación nos mostrará una página con el siguiente texto:

 

Server Error in ‘/’ Application.


Runtime Error

Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine. 

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a “web.config” configuration file located in the root directory of the current web application. This <customErrors> tag should then have its “mode” attribute set to “Off”.

 

 

Este mensaje nos indica que ha ocurrido un error y no se muestra al visitante debido a la configuración del Web.Config que por defecto viene así:

 

<configuration>
    <system.web>
        <customErrors mode="Off"/>
    </system.web>
</configuration>

La forma más rápida para poder ver el error es cambiar el “RemoteOnly” por “Off” pero esto no es para nada recomendable ya que muestra los errores a cualquier visitante de la web pudiendo poner en entredicho la seguridad del sistema.

La tercera configuración que permite el apartado “customErrors” es redirigir a una página específica de error y luego guardar el error en un fichero de log o base de datos o bien enviarlo por mail. 

 

Este tutorial explica cómo implementar esta última opción:

Primero: Modificamos el Web.Config para activar los errores personalizados para que redirija a la página “error.aspx”:

<configuration>
    <system.web>
        <customErrors mode="On" defaultRedirect="error.aspx"/>
    </system.web>
</configuration>

Segundo: Creamos la página “error.aspx” para indicar al usuario qué debe de hacer. Como ejemplo os dejo la página de error personalizada que hicimos en Domitienda.com:

Tercero: Sobreescribir el método “Application_Error()” del fichero “Global.asax” (si no tienes ese fichero en tu proyecto lo puedes agregar). Este método se ejecuta cada vez que ocurre un error sin capturar. En este ejemplo vamos a enviar un mail con el error para que podamos revisarlo y solventarlo cuanto antes:

 

void Application_Error(object sender, EventArgs e)
{

	try
	{
		//Obtenemos el error
		Exception ex = Server.GetLastError();

		//Formateamos el correo con los datos del error
		string bodyMail = "Error en Aplicación<br/>";
		bodyMail+= "<br/>Fecha: " + DateTime.Now.ToShortDateString() + " " + DateTime.Now.ToShortTimeString();
		bodyMail+= "<br/>Descripción: " + ex.Message;
		bodyMail+= "<br/>Origen: " + ex.Source;
		bodyMail+= "<br/>Pila: " + ex.StackTrace;

		System.Net.Mail.MailMessage oMsg = new System.Net.Mail.MailMessage();
		oMsg.From = new System.Net.Mail.MailAddress("error@mydomain.com");
		oMsg.To.Add("webmaster@mydomain.com");
		oMsg.Subject = "Error en Aplicación";
		oMsg.Body = bodyMail;
		oMsg.IsBodyHtml = true;

		System.Net.Mail.SmtpClient smtp = new System.Net.Mail.SmtpClient("mail.mydomain.com");
		smtp.Credentials = new System.Net.NetworkCredential("error@mydomain.com","passCuentaCorreo");

		smtp.Send(oMsg);

		//Limpiamos el error 
		Server.ClearError();
	}
	catch(Exception errorEnEnvioDeError)
	{
		//En caso de fallar el envío de error podíamos probar un método alternativo como guardar "bodyMail" en un fichero de texto o en base de datos
	}
}

 

 

Con este sencillo método tendremos nuestra web protegida ante errores inesperados, el visitante verá una página de error más usable y el adminitrador de la web tendrá el mensaje de error en su buzón de correo inmediatamente para poder solventarlo cuanto antes.

Nos vemos Compilando!!

Creando la capa de datos: Entity Framework vs LINQ to SQL

Una de las cosas que más interés me ha generado durante mi vida como desarrollador es como conseguir una buena capa de persistencia, consistente, flexible y transparente para el nivel de aplicación sin mezclar consultas sql’s o crear manualmente clases que repiten funcionalidad y datos.

He trabajado con varias herramientas, desde las más rudimentarias clases estáticas con métodos que ejecutaban sql “a pelo” hasta clases generadas a mano que por debajo usaban una instancia de DataRow (que por cierto no es serializable y no se puede usar con servicios WCF); hasta que en el framework 4.0 de .NET se incluyó el Entity Framework (EF) y LINQ to Entities.

 

Pero antes, un poco de historia:

Ya en la versión 3.5 de .NET nuestros amigos de Redmond incluyeron una nueva herramienta de O/RM (object relational mapping) conocida como “LINQ to SQL”. Con LINQ to SQL podíamos modelar una base de datos relacional con clases .NET de forma automática lo que nos permitia seleccionar, editar, insertar o eliminar datos tan solo editando las clases y colecciones generadas.

Para poder trabajar con estas clases se añadió soporte para lenguaje “LINQ” (Language Integrated Query) que no es más que un modo de expresar consultas similares al sql normal contra cualquier colección (ya sea generado por el modelador de LINQ to SQL o bien creada manualmente). LINQ incluye tipado, comprobación de las consultas en tiempo de compilación, expresiones lambda y tipos anónimos e intellisense lo que lo convierte en un lenguaje para consultas mucho más potente que el sql clásico.

Con estas dos herramientas juntas podemos obtener una serie de clases generadas automaticamente de una base de datos y trabajar con ellas manipulando datos sin necesidad de escribir una sola linea SQL.

 

Más adelante, con la versión 4.0 de .NET se incluyó ADO .NET Entity Framework y su LINQ to Entities que ofrecía una nueva forma de modelar bases de datos en entidades de forma automática más compleja y flexible pero con un funcionamiento básicamente similar ya que también se trabaja mediante consultas LINQ.

 

Visto esto os preguntareis: “Pues tiene buena pinta pero…¿qué diferencias existen entre LINQ to SQL y Entity Framework?

Aunque son casi lo mismo LINQ to SQL y EF han tenido vidas paralelas y, hoy en día, EF se ha impuesto de manera aplastante. La gran diferencia es que LINQ to SQL se creó con la finalidad de ser un RAD (Rapid Application Development) por lo que se dejaron alguna cosas en el tintero que se solventaron con EF:

  • LINQ to SQL sólo permite conectarse a SQL Server y ser usado en C# o VB.NET. EF en cambio soporta varios proveedores como MySql, Oracle, SQL Server, XML, etc…
  • LINQ to SQL mapea cada tabla/vista como una clase o “entidad” sin permitir herencia, entidades lógicas o entidades de negocio. EF lo implementa completamente.

 

Como veis Entity Framewok está preparado para modelar la capa de datos de una forma más generica y flexible lo que nos permite abordar proyectos de mayor envergadura aunque si lo que buscamos es una forma rápida de modelar nuestra base de datos SQL SERVER y no necesitamos grandes florituras LINQ to SQL nos valdría perfectamente.

En futuras entradas explicaré de forma más practica como modelar una base de datos y como hacer las típicas consultas (Select, Insert, Update, Delete) con Entity Framework.

 

Nos vemos Compilando!

Nace Compilando.ES

La vida de un ingeniero del software pasa por muchas fases.

 

Al principio no le prestas mucha atención a lo que codificas y sólo quieres tener resultados lo más pronto posible sin pensar en las consecuencias; pero llega un momento (usualmente cuando te toca revisar el código meses después) que esas prisas sólo han servido para obtener un producto mediocre, poco flexible e incompresible.

Después empiezas a encontrarte problemas que ya has resuelto en otros proyectos y que has codificado de distintas formas varias veces y empiezas a construir tus propios controles o dll’s que vas usando proyecto tras proyecto para evitar la engorrosa tarea de repetir hasta la saciedad una y otra vez lo mismo. En ese momento empiezas a entender de que va esto de la Ingeniería del Software.

 

Y es que lo bonito de este mundo es que está en constante evolución.

Herramientas que pensabas eran insustituibles meses después están desfasadas. Metodologías que te vendían como definitivas solo son un paso más para la obtención de un producto más limpio y eficaz. Frameworks que aportaban potencia hasta ese momento inalcanzable se convierten en antiguallas con el paso del tiempo.

 

Y lo mismo pasa con los Ingenieros del Software. Esta es una profesión de alto riesgo donde no estar al día significa que has perdido valor, donde no pasarte gran parte de tu tiempo investigando y leyendo a los grandes hace que te quedes un paso por detrás. Y en este mundo, cuando la tecnología te supera, es hora de dejarte a un lado y dejar pasar a los que vienen fuerte apretando por detrás.

 

Es por este mismo motivo que me he animado a crear compilando.es, un pequeño espacio en Internet en el cual depositar mi granito de arena sobre mis experiencias como desarrollador, analista y jefe de equipo y sobretodo un medio en el que poder ayudar y orientar al que tenga dudas y está empenzando con ilusión en este basto mundo que es la Ingeniería del Software.

¿De qué se hablará aquí?

  Sobre todo de tecnologías Microsoft que son las que me han acompañado (hasta ahora y esperemos que por muchos años) en mi aventura como desarrollador pero siempre desde un punto de vista práctico y orientado a aportar, aunque sea minimante, algo de valor y calidad.

.NET, Sql Server, jQuery, servidores Windows, IIS, Visual Studio, metodologías y ayudas para el programador son las principales areas que se tratarán en esta web siempre que tenga el tiempo suficiente para escribir y organizar mis ideas.

 

¿Quien escribe estas líneas?

Me llamo Víctor Fernández Portero, trabajo como Analista, Desarrollador y Jefe de Proyectos desde el 2006 en Domitienda.com, una de las empresas de hosting españolas más especializadas y preparadas en lo que a servicios Windows se refiere.

 

En fin, espero que os paseis por aquí a menudo si os interesa este apasionante mundo y si no os quereis perder nada no dudeis en subscribiros al RSS o seguid mi cuenta de twitter.

 

Nos vemos Compilando!!!