January 2008 - Artículos - Jorge Serrano - MVP Visual Developer - Visual Basic

January 2008 - Artículos

MSDN Code Gallery es el sitio de Microsoft dónde localizaremos buena parte del código de MSDN.

Este enorme repositorio, contiene código, ejemplos, demostraciones, etc., de cualquier producto de Microsoft.

Si buscas ejemplos de "cómo hacer" o quieres simplemente conocer "algo sobre", este es uno de los sitios por dónde deberías empezar.

Acceso directo a MSDN Code Gallery.

Introducción 

En el anterior artículo, veíamos como iniciarnos en la filosofía de n-capas utilizando Microsoft ADO.NET Entity Framework.

Aún nos falta mucho recorrido y este tema nos daría para algunas entradas o artículos más, pero vamos a ir desgranando poco a poco las bondades, problemas, dudas y preguntas que nos pueden surgir a la hora de iniciarnos con LINQ to Entities y las aplicaciones de n-capas.

En el anterior artículo, nos quedamos revisando lo que tiene por "fuera" ADO.NET Entity Framework, pero aún no sabemos lo que tiene por "dentro". Eso es lo que veremos a continuación.

Lo que tiene por “dentro” un elemento ADO.NET Entity Data Model

Ahora bien, vamos a volver al proyecto y ver más detalles relacionados con el EF. Resumiendo nos encontramos con que:

  • Tenemos como hemos dicho al principio, un proyecto de tipo WinForm.
  • Dentro del proyecto hemos agregado un modelo de datos EF.
  • En el asistente creamos una cadena de conexión con el modelo físico que se almacenó en el archivo de configuración de aplicación App.Config.

El aspecto del archivo de configuración de aplicación App.Config es de la siguiente forma:

<?xml version="1.0" encoding="utf-8"?>
<
configuration>
  
...
  <
connectionStrings>
    <
add name="FUTBOL2006Entities" connectionString="metadata=.\Futbol2006.csdl|.\Futbol2006.ssdl|.\Futbol2006.msl;
provider=System.Data.SqlClient;provider connection string=&quot;Data Source=CLUNIA;Initial Catalog=FUTBOL2006;
Integrated Security=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />
  </
connectionStrings>
</
configuration>

Como podemos observar, aquí se nos indica una cadena de conexión y un nombre de proveedor (System.Data.EntityClient).

Respecto a la cadena de conexión observamos que se indican tres ficheros de metadatos (csdl, msl y ssdl) como pudimos ver en el asistente.

La pregunta por lo tanto es… ¿pero dónde están estos metadatos?. ¿Los genera el entorno en tiempo de ejecución?. Si lo hace en tiempo de ejecución, ¿dónde los almacena realmente?. ¿Cómo funcionaría una aplicación típica cliente-servidor?.

Evidentemente, esos tres archivos de metadatos existen ya en el sistema. La pregunta entonces sería saber dónde se encuentran. La respuesta es en el directorio bin/Debug como se indica en la siguiente captura de pantalla.

¿Y qué contiene esos tres archivos?. Contenido XML del modelo. Así de simple.

No vamos a entrar ahora en el detalle más profundo, pero establecen todas las partes de nuestro modelo.

Pero hay algo más que aún no he explicado y que lo haré a continuación.

Todo son clases

Otro aspecto que debemos tener en cuenta es como organiza Microsoft el modelo de entidades.

Para ello, primero acudiremos al visor de clases y observaremos que en nuestro proyecto tenemos un namespace denominado Futbol2006Model (¿os suena que ya hemos utilizado ese nombre en la ejecución del asistente?).

El caso es que analizando ese nombre de espacio, vemos el conjunto de clases creadas de acuerdo al modelo de entidades.

Una vez más, debemos preguntarnos en qué lugar se almacena entonces la información de las clases creadas de acuerdo al modelo de entidades.

En este caso, debemos acudir al fichero de extensión edmx. Se trata de un documento XML con información directa del modelo de entidades, y que enlaza con un fichero (Futbol2006.Designer.vb) que contiene clases parciales escritas en VB y que definen la entidad, sus propiedades, métodos, etc.

Ahora bien, igual estás pensando en qué ocurre si queremos extender las clases del modelo de entidades. ¿Es posible llevarlo a cabo?. La respuesta es sí, pero para poder llevarlo a cabo, deberemos crear otro archivo aparte del Futbol2006.Designer.vb, ya que si incluimos nuestra personalización dentro de ese archivo, al actualizar, refrescar y/o ejecutar nuestra aplicación de acuerdo al modelo, realizará una validación que eliminará el código sobrante, y el código sobrante que no hace falta utilizar al modelo es la personalización que hayamos realizado dentro del archivo Futbol2006.Designer.vb, de ahí que la personalización si la hacemos, debamos hacerlo fuera de ese archivo.

Distribuyendo nuestra aplicación

Aunque nada de lo que hemos visto hasta ahora es despreciable, digamos que ahora viene lo mejor de todo ya que vamos a empezar a discutir la idoneidad de algunas cosas que podríamos hacer o no, y hacernos preguntas interesantes.

En primer lugar pensemos en nuestra aplicación de WinForms como un todo, tal y como lo hemos hecho hasta ahora.

Nuestra aplicación contendrá un modelo de entidades y el ejecutable. Todo en uno.

En este ejemplo, hemos agregado un control Button y un control DataGridView.

El código que hemos agregado es el siguiente:

Imports EntityCapas.FUTBOL2006Model

Public Class MainForm

   
Private Sub btnExecute_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnExecute.Click
      
Dim contexto As New FUTBOL2006Entities
      
Dim players = From p In contexto.Futbolista Where p.Club.Codigo = "RMA" Select p
      
Me.dgvData.DataSource = players
      
Me.dgvData.AutoResizeColumns(DataGridViewAutoSizeColumnsMode.AllCells)
   
End Sub

End
 Class

En el caso de distribuir nuestra aplicación, tendremos un ejecutable que corresponderá con nuestra aplicación Windows.

Crearemos para esta prueba, un directorio Windows vacío e insertaremos en este directorio el fichero ejecutable de nuestra aplicación, para acto seguido, ejecutar la aplicación.

Al pulsar sobre el botón, se generará un error. Evidentemente, nos hemos olvidado de llevarnos el archivo App.Config al directorio dónde está el ejecutable. ¿Os acordáis que ese archivo tenía la cadena de conexión con el modelo físico?.

Bien, nos llevamos entonces el fichero App.Config allí y ejecutamos nuevamente la aplicación y pulsamos el botón.

Ahora aparece un mensaje que nos indica que faltan los ficheros que se indican en la cadena de conexión del App.Config y que corresponde con los archivos csdl, ssdl y msl.

Nos vamos a nuestro proyecto, y copiamos esos archivos en el directorio dónde estamos poniendo nuestra aplicación de demo.

Ejecutamos nuevamente nuestra aplicación, pulsamos el botón, y ahora sí, vemos como los datos son recogidos correctamente en la aplicación sin ningún tipo de error.

De todo este proceso, sacamos varias conclusiones:

  • Al distribuir nuestra aplicación, debemos indicarle la cadena de conexión al modelo físico y a los ficheros metadatos.
  • Por defecto, la cadena de conexión se crea en el archivo App.Config, por lo que distribuir este archivo, puede accarearnos problemas de seguridad. Una posible solución sería encriptar la cadena de conexión, pero seguimos teniendo altos riesgos de intrusión al poder utilizar herramientas que permitan romper la cadena de conexión.
  • Adicionalmente, debemos también distribuir los archivos de metadatos, lo cual hace más pesada la distribución de nuestra aplicación.

Así que con todo esto, nos vemos delante de una interesante encrucijada. ¿Cómo debemos actuar?. Por supuesto que depende del escenario, pero lo ideal es que los clientes tengan el menor acceso posible a información sensible, y una cadena de conexión o los metadatos lo es.

Girando la tuerca por primera vez y buscando una mejor opción

En primer lugar, estudiaremos la posibilidad de reducir los archivos de distribución a la hora de trabajar con EF o mejorar la forma de distribuir nuestra aplicación utilizando el modelo de EF.

De primeras, hemos visto que para distribuir la aplicación, debemos distribuir:

  • El fichero ejecutable.
  • El fichero de configuración.
  • Los tres archivos correspondientes a los metadatos.

Este tipo de distribución no es bajo mi punto de vista el tipo de distribución ideal, pero a priori es la forma más básica de hacerlo.

Pensemos ahora entonces, en intentar mejorar este tipo de distribución, modulando la aplicación de alguna manera. Para ello, crearemos en primer lugar una solución con dos proyectos.

El primer proyecto será el del proyecto WinForm que hemos hecho hasta ahora.

El segundo proyecto será una biblioteca de clases dentro de la cuál agregaremos el modelo de EF.

Luego desde el primer proyecto WinForm, consumiremos la biblioteca de clases. De todos los modos, pensando así de sopetón, deduciremos que el ensamblado de la biblioteca de clases debería tener también los “famosos” archivos de metadatos… ¿o quizás no?. Eso es lo que veremos a continuación.

Agregaremos a la solución por lo tanto, un nuevo proyecto de biblioteca de clases. Aparecerá por defecto una clase que eliminaremos porque no la vamos a usar para nada, así que la idea es tener el esqueleto de un proyecto.

Dentro de ese esqueleto agregaremos un nuevo elemento de tipo ADO.NET Entity Data Model, y a continuación realizaremos con ayuda del asistente las mismas acciones que vimos anteriormente para preparar el nuevo modelo de datos.

Una vez superado este paso, agregaremos a nuestro proyecto WinForm una referencia al ensamblado de la biblioteca de clases que contiene el modelo y escribiremos el código de nuestra pequeña aplicación.

El código quedará de la siguiente manera (se aprecia que solo se modificaría con respecto al anterior código la importación del correspondiente namespace):

Imports EntityClasses.FUTBOL2006Model

Public Class MainForm

   
Private Sub btnExecute_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnExecute.Click
      
Dim contexto As New FUTBOL2006Entities
      
Dim players = From p In contexto.Futbolista Where p.Club.Codigo = "RMA" Select p
      
Me.dgvData.DataSource = players
      
Me.dgvData.AutoResizeColumns(DataGridViewAutoSizeColumnsMode.AllCells)
   
End Sub

End
 Class

Ahora llega el turno de crear el ejecutable y distribuir nuestra aplicación. En este punto tendremos las siguientes partes separadas que juntas conforman la distribución de la aplicación:

  • El fichero ejecutable.
  • El fichero de configuración.
  • Los tres archivos correspondientes a los metadatos.
  • El ensamblado de la biblioteca de clases.

Analizando el resultado, veremos que el hecho de haber apartado el modelo de datos a una biblioteca de clases ha hecho que generemos un fichero más en su distribución, el correspondiente al ensamblado del modelo de datos.

Siempre podremos, no obstante, utilizar alguna herramienta para unir ensamblados o algo similar, pero aún y así, lo ideal sería poder reducir el número de ficheros a distribuir de forma que el proceso de implantación fuera más sencillo y a ser posible, más modular. Cuantos más ficheros a distribuir, más riesgos de que haya algo que se nos pueda estar olvidando, y cuanto menos modular más encorsetado. El equilibrio entre ambos es difícil, pero al mismo tiempo necesario.

En el siguiente artículo, veremos como podemos acercarnos un poco más hacia el comienzo de lo que son las n-capas con EF.

Introducción

En las entradas anteriores que he tratado sobre LINQ, hemos visto inicialmente (Parte 1 y Parte 2) un ejemplo de EF (Entity Framework o ADO.NET Entity Framework) y posteriormente un caso especial que ocurría en Visual Basic 2008 pero no en C# 3.0.

En esta ocasión, vamos a acercarnos a la programación en n-capas. No es que vayamos a ver un ejemplo completo de n-capas ni tampoco que vayamos a entrar en las n-capas de lleno, pero sí vamos a hacer una aproximación hacia las n-capas utilizando EF para que sirva de modelo inicial de aquellos aspectos típicos con los que nos podemos encontrar al principio.

Acercándonos a las necesidades

Cuando trabajamos con EF, lo que solemos hacer es iniciar un proyecto (del tipo que sea) y agregar un elemento de tipo EF (ADO.NET Entity Data Model) para crear el modelo de entidades y trabajar con él.

El resultado, suponiendo que hemos elegido como plantilla de proyecto un WinForm, es un ejecutable con el modelo de entidades dentro de él y con su fichero de configuración (App.Config).

Preparando ADO.NET Entity Data Model

Cuando agregamos al proyecto un elemento de tipo ADO.NET Entity Data Model, Visual Studio 2008 lanza un asistente.

La primera pantalla del asistente nos preguntará acerca del modelo de contenido que queremos elegir.

En nuestro caso elegiré generarlo desde una base de datos.

A continuación, pulsaremos el botón Next para continuar con el asistente.

En este punto, aparecerá una ventana con la información de la conexión que queremos utilizar (lógicamente, crearemos una nueva conexión en el caso de que no tengamos ninguna preparada previamente).

En esta ventana, indicaremos la cadena de conexión y agregaremos esa cadena de conexión al archivo App.Config de nuestra aplicación WinForm seleccionando la opción para tal acción. El nombre de esa conexión a la entidad es en mi caso Futbol2006Entities.

Si observamos con detenimiento esta pantalla, veremos que en la cadena de conexión aparecen varios ficheros que tienen relación con la propiedad metadata (metadatos).

Esos tres ficheros de extensión csdl, ssdl y msl, tiene relación directa con los metadatos y serán objeto de una próxima parada.

Una vez que hemos elegido la conexión y hemos establecido sus parámetros, pulsaremos el botón Next para continuar con nuestro asistente.

La ventana que aparece la conocéis muy bien a estas alturas. Se trata de una ventana dentro de la cual podremos elegir los elementos que queremos agregar al modelo.

Para finalizar pulsaremos el botón Finish.

Lo que tiene por “fuera” un elemento ADO.NET Entity Data Model

Una vez agregado nuestro modelo de entidades, podemos observar varias cosas a tener en cuenta.

Por un lado, hay una ventana en Visual Studio 2008, que tiene el nombre de Model Browser.

En esta ventana, podemos consultar la información relativa al modelo de entidades que hemos agregado al proyecto.

Podremos de esta manera acceder a los tipos de entidades agregados, sus asociaciones, las tablas y claves del modelo de almacén de datos, etc.

También podemos acceder a la ventana Propiedades para cada elemento de esta ventana, con el fin de personalizar el modelo si es esa nuestra intención.

En otro orden de cosas, en el diseñador de entidades veremos el modelo de entidades agregado, tal y como hemos visto en ejemplos anteriores.

Y adicionalmente, podremos acceder también de acuerdo al modelo, a los detalles de mapeo de las entidades a través de una ventana que aparecerá en Visual Studio 2008 con el nombre de Mapping Details.

Hasta aquí, hemos podido ver los aspectos generales de cualquier aplicación estándar que utilice LINQ y en su caso EF. Sin embargo, aún no hemos visto lo que tiene "por dentro" EF, y eso es lo que empezaremos a ver en la próxima entrada que será dentro de muy muy muy poco tiempo.

Microsoft ha publicado gratuitamente un libro electrónico sobre Microsoft SQL Server 2008.

El libro pertenece a la colección 6187 de eLearning de Microsoft, y queda incluido dentro de tres recursos más:

  • 6188: Lo nuevo en SQL Server 2008 para plataformas de datos empresariales
  • 6189: Lo nuevo en SQL Server 2008 para Business Itelligence
  • 6190: Lo nuevo en SQL Server 2008 para desarrollo de base de datos

El curso puede ser adquirido gratuitamente en este enlace.

Publicado por Jorge Serrano | 9 comment(s)
Archivado en:

Microsoft ha publicado un PowerToy nuevo para Visual Studio 2008.

Este juguete, permite navegar en forma de TreeView, por el código de un proyecto, por sus tipos, miembros, etc., pudiendo acceder a continuación y a través de él, al editor de Visual Studio 2008.

El complemento es realmente pequeño, la descarga apenas ocupa 700 Kb, aunque lo encontraremos eso sí en inglés.

Lo mejor es que el código del PowerToy está disponible y podemos acceder a él si lo queremos.

Microsoft ha sacado a la luz una "cosa" denominada Visual Studio 2008 Web Deployment Projects.

Con este palabro, Microsoft ha querido facilitar la vida de los arquitectos y desarrolladores a modo de add-in o complemento.

El complemento que os comento, se instala en Visual Studio 2008 y tiene un tamaño de apenas 690 Kb.

Si reducido es su tamaño, grande es su utilidad, porque nos permite cargar como entrada un proyecto Web existente y generar un proyecto Web precompilado como salida, facilitándonos la tarea de implantación. Por otro lado, Microsoft nos indica que este complemento NO nos modifica los ficheros del proyecto fuente que dimos como entrada del proceso.

Las funcionalidades que tenía Visual Studio 2005 Web Deployment Projects las sigue teniendo ahora Visual Studio 2008 Web Deployment Project.

 Si quieres acceder al enlace de descarga de este complemento para Visual Studio 2008, lo puedes hacer desde este enlace.

Hace poco tiempo, os mostraba en otra entrada unos enlaces para poder comparar las versiones de Visual Studio 2008.

Sin embargo, en aquella comparación se echaba de menos ver información de la familia Express Edition.

En esta ocasión, os indico tres enlaces para acceder a la información de comparación de versiones Visual Studio 2008.

Los enlaces nos llevan a la misma información pero en diferentes formatos.

Las comparaciones están divididas en áreas diferentes, y creo que constituye una comparación mucho más completa que la que os indiqué en la otra entrada de hace unos días.

Acceso a la comparación de versiones Visual Studio 2008:

Publicado por Jorge Serrano | 6 comment(s)
Archivado en:

Visual Studio 2008

LINQ to Entities (L2E) 

Parte 2: Resolviendo problemas con el volcado de datos a un control DataGridView

Resumen general de lo publicado sobre LINQ hasta el momento:

Introducción

En la anterior entrega de LINQ to Entities os comentaba como trabajar con datos y LINQ to Entities de una manera introductoria.

Era un sencillo ejemplo que quería que sirviera de patrón o modelo introductorio para quienes deseen tomar contacto con LINQ to Entities.

En ese artículo me salté (a propósito) muchos aspectos más introductorios si cabe sobre LINQ to Entities que me hubiera gustado abordar más adelante, pero que no voy a hacer ya que Juan Carlos González (CIIN) se me ha adelantado con una excelente entrada que aclara todas las cosas de las que quería hablar.

El caso es que al final de la primera entrada que escribí acerca de LINQ to Entities os comentaba lo siguiente:

"Ahora bien, si observamos con atención esta pantalla y el código escrito, y en concreto la instrucción Select p.Id, p.Nombre, p.Sexo, p.FechaNacimiento, CodigoPaisNacimiento = p.Pais.Codigo, CodigoClub = p.Club.Codigo, p.Posicion, veremos que el orden de los campos mostrados en el DataGridView no es el que esperábamos, o al menos no el que nos gustaría obtener. Además tenemos también una claúsula OrderBy que indicaría teóricamente un orden. ¿Porqué se da este  comportamiento?."

Y de eso os voy a hablar aquí. De esa "extraña" ordenación, del comando Select y del comando OrderBy.

¿Que es lo que ocurre para que el comportamiento del volcado de datos no sea es comportamiento esperado?.

Repasando el ejemplo que os propuse, en él se ejecutaba una sentencia LINQ completa (a continuación os pongo parte de la misma):

                          ...
                          Select p.Id, p.Nombre, p.Sexo, p.FechaNacimiento, CodigoPaisNacimiento = p.Pais.Codigo, _
                          CodigoClub = p.Club.Codigo, p.Posicion _
                          ...

Lo lógico es pensar que los datos que extraerá LINQ serán de la forma:
 
Id, Nombre, Sexo, FechaNacimiento, CodigoPaisNacimiento, CodigoClub, Posicion
 
Sin embargo, la captura de pantalla que os mostraba en la entrada, muestra un orden muy diferente:
 
CodigoClub, CodigoPaisNacimiento, FechaNacimiento, Id, Nombre, Posicion, Sexo
 
¿Porqué?.

Ante esto nos podemos poner a investigar algo que nuestra razón llegue a comprender y por eso, una forma de ver lo que ocurre es investigando, así que con VS 2008 como herramienta (no hace falta usar Reflector for .NET, pero si alguno quiere lo puede hacer y extraerá las mismas conclusiones...), observamos con el Watch de VS 2008 que los resultados que obtenemos nos muestra esos datos de forma ordenada según la instrucción Select

Es decir, el método ToString() nos muestra los datos ordenadamente de acuerdo al Select de LINQ, de hecho, basta con ejecutar el siguiente comando para observar que los datos mostrados para una determinada lista aparecen ordenados según esa sentencia Select:

datos.ToList().Item(0).ToString()

Investigando un poco más del porqué de esta situación, vemos que en el Watch los datos aparecen ordenados alfabéticamente: 

 

La primera pregunta por lo tanto es porqué ordena alfabéticamente .NET los datos.

En sí, cada dato corresponde con una propiedad y el hecho de que aparezcan ordenados no representa ninguna anomalía. Por lo tanto, el hecho de que aparezcan ordenados no es un problema (descartamos esto por lo tanto).

Después de ver este funcionamiento en VB 2008, la siguiente pregunta que nos hacemos o que nos podemos hacer es: ¿funcionará de la misma manera en C# 3.0?.

Si hacemos el mismo ejemplo de la anterior entrada pero para C#, veremos con el Watch que el método ToString() nos devuelve los datos igual que VB 2008, y que las propiedades de los elementos de cada resultado aparece ordenada alfabéticamente. Todo esto igual que en VB 2008.

Sin embargo, a la hora de mostrar los datos en el DataGridView, los datos aparecen en el mismo orden que la Select de LINQ.

Entonces,... ¿porqué en VB 2008 aparecen los datos mostrados anómalamente en el DataGridView y en C# 3.0 aparecen bien?.

Una vez más, podemos llegar a pensar en que OrderBy puede tener (a lo mejor) la culpa, así que si ponemos OrderBy tal y como está en el ejemplo original:

      Dim datos = From p In contexto.Futbolista _
                          Where p.Club.Codigo = Me.codeClub _
                          Select p.Id, p.Nombre, p.Sexo, p.FechaNacimiento, CodigoPaisNacimiento = p.Pais.Codigo, _
                          CodigoClub = p.Club.Codigo, p.Posicion _
                          OrderBy Id, Nombre, Sexo, FechaNacimiento, CodigoPaisNacimiento, CodigoClub, p.Posicion

Observaremos que da igual, los resultados del DataGridView en VB 2008 siguen saliendo mal ordenados de acuerdo a la Select de LINQ.

El caso es que OrderBy ordena los elementos por filas, no por columnas, pero Select sí ordena los datos por columnas, por lo que la explicación final es que VB 2008 y LINQ to Entities, extrae y vuelca mal los datos hacia el DataGridView.

¿Es un bug?.

En mi opinión es un mal funcionamiento y sí, puede calificarse como un bug.

¿Se resolverá el bug?.

Este mal funcionamiento ya lo he reportado a Microsoft (no sé si alguien lo habrá reportado antes) y sé que el equipo de LINQ to Entities está ya trabajando con este tema.

Recordemos que LINQ to Entities está aún en fase Beta 3 y no está en versión RTM definitiva.

¿Qué forma tenemos de resolver este problema?.

Existen varias, pero la "menos sucia" es mapear los elementos al DataGridView de forma que aparezcan ordenados.

La parte del ejemplo de la entrada inicial que hiciese las cosas como queríamos desde un principio quedaría de la siguiente forma:

Imports LINQtoEntities.Futbol2006Model
 
Public Class MainForm

   ...

   
Private Sub btnSelectPlayers_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnSelectPlayers.Click
      ' Recuperamos la información que queremos buscar
      Dim codeClub As String Me.cboClubs.SelectedValue.ToString()
      
' Obtenemos los datos de Futbolistas segel equipo seleccionado
      Dim datos = From p In contexto.Futbolista _
                          Where p.Club.Codigo = Me.codeClub _
                          Select p.Id, p.Nombre, p.Sexo, p.FechaNacimiento, CodigoPaisNacimiento = p.Pais.Codigo, _
                          CodigoClub = p.Club.Codigo, p.Posicion _
                          OrderBy Id, Nombre, Sexo, FechaNacimiento, CodigoPaisNacimiento, CodigoClub, p.Posicion
      
' Volcamos los datos en el DataGridView
      Me.dgvPlayers.DataSource = datos
      ' Mapeamos los resultados para mostrarlos adecuadamente en el control DataGridView
      Me.dgvPlayers.Columns(0).DataPropertyName = "Id"
      Me.dgvPlayers.Columns(0).HeaderText = "Id"
      Me.dgvPlayers.Columns(1).DataPropertyName = "Nombre"
      Me.dgvPlayers.Columns(1).HeaderText = "Nombre"
      Me.dgvPlayers.Columns(2).DataPropertyName = "Sexo"
      Me.dgvPlayers.Columns(2).HeaderText = "Sexo"
      Me.dgvPlayers.Columns(3).DataPropertyName = "FechaNacimiento"
      Me.dgvPlayers.Columns(3).HeaderText = "FechaNacimiento"
      Me.dgvPlayers.Columns(4).DataPropertyName = "CodigoPaisNacimiento"
      Me.dgvPlayers.Columns(4).HeaderText = "CodigoPaisNacimiento"
      Me.dgvPlayers.Columns(5).DataPropertyName = "CodigoClub"
      Me.dgvPlayers.Columns(5).HeaderText = "CodigoClub"
      Me.dgvPlayers.Columns(6).DataPropertyName = "Posicion"
      Me.dgvPlayers.Columns(6).HeaderText = "Posicion"
      ' Ajustamos los datos al control
      Me.dgvPlayers.AutoResizeColumns(DataGridViewAutoSizeColumnsMode.AllCells)
   
End Sub

   ...

End
 Class

De esta manera, aparecerán los datos correctamente mapeados.

A mí me parece una guarrada (con perdón), pero de momento no hay otra forma más elegante a la espera de que se resuelva este pequeño problema.

Espero que contando esto por aquí, le pueda servir de ayuda a más de uno si se encuentra con este extraño funcionamiento en VB 2008, y que lo tengamos resuelto en la versión definitiva de ADO.NET Entity Framework (pedir es gratis ¿verdad?).

Visual Studio 2008

LINQ to Entities (L2E) 

Resumen general de lo publicado sobre LINQ hasta el momento:

Después de haber visto introductoriamente LINQ to DataSet y LINQ to SQL, ahora le toca el turno a LINQ to Entities dentro del paradigma de LINQ y ADO.NET.

Recordando el modelo de Microsoft .NET Framework 3.5, observamos que LINQ to Entities (LINQ sobre Entidades) se encuentra dentro de LINQ y ADO.NET. El diagrama general de la arquitectura LINQ es el siguiente:

Mientras que LINQ to SQL es utilizado para trabajar con fuentes de datos SQL Server, LINQ to Entities es utilizado fundamentalmente (además de por otras razones) para trabajar con múltiples fuentes de datos.

Para desarrollar el siguiente ejemplo de introducción a LINQ to Entities al igual que en el caso del ejemplo de LINQ to SQL, vamos a utilizar el modelo de datos utilizado en el excelente libro de Octavio Hernández "C# 3.0 y LINQ”.

Iniciaremos un nuevo proyecto de VB utilizando como plantilla la plantilla de aplicación para Windows y agregaremos un nuevo elemento en el proyecto.

El nuevo elemento será de tipo ADO.NET Entity Data Model y de extensión edmx. A ese elemento le daremos el nombre de Futbol2006 como se indica en la siguiente imagen:

Nada más insertar este elemento, se iniciará un asistente con el cual podremos agregar las tablas, vistas y procedimientos almacenados de la fuente de datos con la que queremos trabajar.

En mi caso agregaré la fuente de datos de FUTBOL2006 y las tablas de la base de datos.

Una vez hecho esto, veremos que por un lado se agregan al proyecto los ensamblados necesarios para trabajar con datos y LINQ, y por otro lado, aparece en pantalla un diseñador de los objetos relacionales seleccionados.

Como podremos observar, las relaciones entre tablas aparecen dentro del diagrama del modelo de datos de entidades. Cada entidad queda perfectamente representada y como aspecto adicional, veremos que se establecen unas relaciones entre tablas de manera tal que la clave extranjera de una tabla aparezca en el apartado Navigation Properties de la entidad.

Partiendo por lo tanto de este modelo de entidades, vamos a trabajar ahora con él.

Dentro del formulario, vamos a agregar un control ComboBox (cboClubs), un control Button (btnSelectPlayers) y un control DataGridView (dgvPlayers).

Nuestro ejemplo en ejecución mostrará los jugadores de un club de futbol.

A continuación, vamos a escribir el siguiente código:

Imports LINQtoEntities.Futbol2006Model
 
Public Class MainForm

   
' Declaramos el contexto para usarlo en todo el programa
   Private contexto As New Futbol2006DataContext()

   
Private Sub btnSelectPlayers_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnSelectPlayers.Click
      ' Recuperamos la información que queremos buscar
      Dim codeClub As String Me.cboClubs.SelectedValue.ToString()
      
' Obtenemos los datos de Futbolistas segel equipo seleccionado
      Dim datos = From p In contexto.Futbolista _
                          Where p.Club.Codigo = Me.codeClub _
                          Select p.Id, p.Nombre, p.Sexo, p.FechaNacimiento, CodigoPaisNacimiento = p.Pais.Codigo, _
                          CodigoClub = p.Club.Codigo, p.Posicion _
                          OrderBy Id, Nombre, Sexo, FechaNacimiento, CodigoPaisNacimiento, CodigoClub, p.Posicion
      
' Volcamos los datos en el DataGridView
      Me.dgvPlayers.DataSource = datos
      
' Ajustamos los datos al control
      Me.dgvPlayers.AutoResizeColumns(DataGridViewAutoSizeColumnsMode.AllCells)
   
End Sub

   Private Sub MainForm_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
      
' Ejecutamos el mpara cargar los Clubs de Futbol
      LoadClubs()
   
End Sub

   Private Sub LoadClubs()
      
' Cargamos los Clubs de Futbol
      Dim datos = From p In contexto.Clubs Select p.Codigo, p.Nombre
      
Me.cboClubs.DataSource = datos
      
' Indicamos el valor a mostrar
      Me.cboClubs.DisplayMember = "Nombre"
      ' Indicamos el co clave asociado al valor mostrado
      Me.cboClubs.ValueMember = "Codigo"
   End Sub

End
 Class

El resultado de ejecutar nuestra aplicación de ejemplo es el que se indica a continuación:

Ahora bien, si observamos con atención esta pantalla y el código escrito, y en concreto la instrucción Select p.Id, p.Nombre, p.Sexo, p.FechaNacimiento, CodigoPaisNacimiento = p.Pais.Codigo, CodigoClub = p.Club.Codigo, p.Posicion, veremos que el orden de los campos mostrados en el DataGridView no es el que esperábamos, o al menos no el que nos gustaría obtener. Además tenemos también una claúsula OrderBy que indicaría teóricamente un orden. ¿Porqué se da este comportamiento?.

Esto lo dejaremos así hasta la siguiente entrega que será dentro de muy poco.

Actualización de esta entrada (25/01/2008):

El equipo de Visual Basic ha creado unos foros piloto (3 en concreto) a los cuales podemos acudir para enviar bugs sobre Visual Basic dentro de la plataforma .NET (no sobre Visual Basic 6.0 ó anteriores).

Los foros piloto son un medio para enviar los bugs que podamos encontrar con respecto a Visual Basic, pero también tenemos la posibilidad de enviar nuestros bugs en el conocido sitio de Microsoft Connect.

Los 3 foros piloto abiertos por el momento son el dedicado al lenguaje Visual Basic, a la interoperabilidad y actualización de Visual Basic, y a los Power Packs de Visual Basic.

Podréis encontrar más información acerca de estos foros y como usarlos en el blog oficial del equipo de Visual Basic.

En otra entrada en mi blog, os comentaba hace tiempo la existencia de un conjunto de iconos gratuitos muy interesante para nuestras aplicaciones.

En esta ocasión, os invito a visitar otra página web con un montón de iconos más que os resultará (espero) muy útil también.

Publicado por Jorge Serrano | 7 comment(s)
Archivado en:

Visual Studio 2008

LINQ to SQL (L2SQL) 

Resumen general de lo publicado sobre LINQ hasta el momento:

Dentro del paradigma del trabajo con LINQ y ADO.NET, nos encontramos con LINQ to SQL.

En otras entradas de este blog, nos introdujimos entre otros en LINQ to DataSet, y ahora le llega el turno a LINQ to SQL.

Dentro de los ámbitos del uso de ADO.NET y LINQ, encontramos dentro de Microsoft .NET Framework 3.5 la posibilidad de trabajar con LINQ to DataSet, LINQ to SQL y LINQ to Entities.

Para trabajar con otros datos no accesibles directamente desde ADO.NET, podemos utilizar LINQ to XML y LINQ to Objects.

El modelo de Microsoft .NET Framework 3.5 es el siguiente:

En nuestro caso vamos a trabajar con la parte correspondiente con LINQ to SQL.

LINQ to SQL es utilizado para trabajar con fuentes de datos SQL Server, si bien hay intentos en internet para trabajar con otras fuentes de datos diferentes.

Para desarrollar aplicaciones de múltiples base de datos, utilizaremos LINQ to Entities que ofrece además muchas más posibilidades que LINQ to SQL.

Para realizar este ejemplo o iniciar la toma de contacto con LINQ to SQL, vamos a utilizar el modelo de datos utilizado en el excelente libro de Octavio HernándezC# 3.0 y LINQ”.

Iniciaremos un nuevo proyecto de VB utilizando como plantilla la plantilla de aplicación para Windows y agregaremos un nuevo elemento en el proyecto.

El nuevo elemento será de tipo LINQ to SQL Classes y de extensión dbml (Database Markup Language). A ese elemento le daremos el nombre de Futbol2006 como se indica en la siguiente imagen:

Nada más insertar este elemento, veremos que por un lado se agregan al proyecto los ensamblados necesarios para trabajar con datos y LINQ, y por otro lado, aparece en pantalla un diseñador de los objetos relacionales vacío.

La idea es trabajar con él, pero antes de poder trabajar con el diseñador, deberemos agregar cierta información al mismo.

Para agregar esa información, la primera acción que realizaremos por lo tanto, será la de crear una conexión de datos con la base de datos FUTBOL2006.

Una vez establecida la conexión de datos, arrastraremos y soltaremos las tablas del modelo que queremos que aparezca en el diseñador de los objetos relacionales.
En el ORM observaremos entonces algo similar a lo siguiente.

Una particularidad en el diseñador, es que las relaciones entre tablas, quedan reflejadas dentro del modelo.

Partiendo de nuestro modelo de objetos relacionales, podemos trabajar con los objetos representados como si estuviéramos haciéndolo con la base de datos directamente.

A partir de aquí, trabajar con el modelo es coser y cantar.

En este ejemplo, vamos a agregar al formulario un control Button (btnSelectPlayers) y un control DataGridView (dgvPlayers).

Nuestro ejemplo en ejecución mostrará los jugadores de un club de futbol.

A continuación, vamos a escribir el siguiente código:

Public Class MainForm

   
' Declaramos el contexto para usarlo en todo el programa
   Private contexto As New Futbol2006DataContext()

   
Private Sub btnSelectPlayers_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnSelectPlayers.Click
      
' Obtenemos los datos de Futbolistas segel equipo seleccionado
      Dim datos = From p In contexto.Futbolistas Where p.CodigoClub = Me.cboClubs.SelectedValue.ToString() Select p
      
' Volcamos los datos en el DataGridView
      Me.dgvPlayers.DataSource = datos
      
' Ajustamos los datos al control
      Me.dgvPlayers.AutoResizeColumns(DataGridViewAutoSizeColumnsMode.AllCells)
   
End Sub

   Private Sub MainForm_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
      
' Ejecutamos el mpara cargar los Clubs de Futbol
      LoadClubs()
   
End Sub

   Private Sub LoadClubs()
      
' Cargamos los Clubs de Futbol
      Dim datos = From p In contexto.Clubs Select p.Codigo, p.Nombre
      
Me.cboClubs.DataSource = datos
      
' Indicamos el valor a mostrar
      Me.cboClubs.DisplayMember = "Nombre"
      ' Indicamos el co clave asociado al valor mostrado
      Me.cboClubs.ValueMember = "Codigo"
   End Sub

End
 Class

El resultado de ejecutar nuestra aplicación de ejemplo es el que se indica a continuación:

Espero que el ejemplo sea lo suficientemente descriptivo como para entender de forma básica, como funciona LINQ to SQL.

Nada tiene que ver esto de forma directa con el avance tecnológico, ni tampoco tiene nada ver con lo que normalmente cuento por aquí, cosas así como el lanzamiento de un nuevo producto Software o la aparición de una nueva tecnología, pero es que si no lo cuento reviento, os lo prometo.

Cuando empecé en esto de la informática hace casi 15 años ya, concretamente cuando empecé la Universidad (porque antes de eso los ordenadores de lejos), muy poca gente sabía a ciencia cierta lo que era eso de los bits, los bytes, los "kBytes" o kilobytes, los "megas" o megabytes, y mucho menos después eso de los gigas o gigabytes, eso era ya para nota. Y ya no quiero hablar de lo que más mola ahora y que aún por suerte no está en boca de los usuarios corrientes, hablo de los "teras" o terabytes, o de los "petas" o petabytes, exa, zetta, yotta, bronto, geop... que sino...

Recuerdo el comentario de la gente "normal" que tenía alrededor. "Vosotros los informáticos, usais una jerga muy rara. Hablais en un lenguaje que nadie entiende."... efectivamente, éramos los bicho raros, y en ese justo momento, yo me erguía todo lo que podía (los pequeñitos como yo no lo podemos hacer durante mucho tiempo porque nos cansamos de estar tan lejos del suelo) y sacábamos pecho.

Tal era la envidia que se formaba alrededor nuestra, que había mucha gente que quería aprender el dialecto técnico que salía de nuestras bocas, y muchos se quedaban en el camino (lógico, si es que nuestro idioma no es fácil y requiere su dedicación leñe).

Sin embargo, de un tiempo a esta parte, todo el mundo habla de "megas" y ahora desde hace poco de "gigas". Digamos que han aprendido a hablar como nosotros... bueno, al menos dicen las mismas palabras aunque a veces no sepan muy bien si las utilizan correctamente o no, pero mejor eso que nada ¿verdad?.

La pasada semana sin ir más lejos, me encontraba comiendo en un restaurante con Cristina, una compañera de Plain Concepts. Al lado nuestro, una mesa con unas diez personas de la construcción reponiendo fuerzas después de dejárselas poniendo ladrillos durante toda la mañana.

En eso que de esa mesa (la teníamos pegada a la nuestra, que nadie piense que estábamos metidos en su conversación) oigo decir... "Tío, ¿y cuántas "megas" tiene la tarjeta de tu móvil?. Compráte una de esas grandes que tiene "gigas" y podrás hacer muchas más fotos".

En ese instante le dije a Cristina, tengo que escribir de esto como sea en Geeks.ms, y es que... ¿cuál es la unidad social de medida?.

Hemos pasado de medir las cosas en kilómetros, metros, kilogramos, gramos, litros, etc., a medir también ciertas "cosas" según la unidad social de medida, esto es... en "megas" y en "gigas".

De hecho, la unidad social de medida no es el saber cuánto es 1 "mega" o cuánto es 1 "giga" (a muy poca gente le interesa cuando llega a un comercio a comprar una tarjeta de memoria), sino "¿cuánto puedo almacenar en 1 "mega" o en 1 "giga"?", y es que claro... todo depende.

Depende del dispositivo, de sus características, de muchos factores técnicos. Así y hablando en términos generales, si hablamos por ejemplo una cámara de fotos, la medida tiene su simbología en forma de fotos, es decir: el tendero te informará: "En esta cámara, se pueden hacer 100 fotos con esta tarjeta de 500 "megas"". El usuario que no tiene mucha idea de términos informáticos pero que no se perdió las reglas básicas de trigonometría piensa rápidamente... "2+2 = 4, Así que si quiero almacenar 200 fotos, necesitaré 1000 "megas"", a lo que el avispado tendero le responde... "¡Ah! usted lo que necesita entonces es 1 "giga"". Y ahí empieza una relación entre mitad curiosidad, mitad "y a mí qué", pero la realidad lleva a que la persona que necesita almacenar 200 fotos adquiere una nueva nomenclatura dialéctica que tiene relación directa con la capacidad que se puede guardar en su nuevo dispositivo. Hemos creado la unidad social de medida: el "mega" y el "giga".

De hecho, ese mismo usuario, luego irá sacando pecho (como lo hacía yo hace años en la casa de mis padres) comentando a sus colegas de trabajo lo que se puede almacenar en 1 "mega" y en 1 "giga".

Eso sí, cuando se le explica al usuario que en una cámara de fotos con nosecuantos píxels marca abc se puede almacenar 100 fotos en 500 "megas" y que en una cámara de marca abc de nosequé píxels se puede almacenar 50 fotos en las mismas 500 "megas", el usuario sufre un pequeño shock del que le cuesta salir al principio, pero del que se repone poco después cuando ante la duda se dice asímismo... "Me compro dos tarjetas de igual capacidad y así puedo almacenar el doble"... un razonamiento de supervivencia genial sin duda, sí.

Lo realmente cierto en todo esto es que el mundo evoluciona y muy rápido, a veces demasiado como para que tomemos conciencia de la cosas. Tan rápido avanza que hasta mi madre habla de "megas" y "gigas" no se aún bien si es porque como me lo ha oído comentar tantas veces ya se encuentra familiarizada con los términos, si es que de tanto verlo en la televisión o en la prensa con anuncios de grandes superficies o similares ya es una unidad de medida que la suena como algo normal, o si es porque a la hora de hacer la compra, los señores y señoras que están esperando a comprar hablan de esas cosas entre ellos para pasar el rato mientras les llega su turno, lo único cierto de todo es que ahora mismo existe una unidad social de medida para todo el público con el cual la gente se ha acercado al ámbito informático y tecnológico, la "mega" y el "giga", y en un futuro cercano y tal y como evoluciona todo, hablarán usando otra unidad de medida superior.

Como cambia la historia. Ahora mismo, los que me parecen bichos raros son los usuarios. :-)

Publicado por Jorge Serrano | 7 comment(s)
Archivado en:

Microsoft ha publicado los pósters de los tipos y Namespaces más usados de Microsoft .NET Framework 3.5.

Un documento que debe estar siempre cerca de los desarrolladores de .NET.

Los pósters solo están disponibles en inglés y francés, y tienen tamaños diferentes dependiendo del tipo de descarga.

La descarga puede encontrarse en formato XPS y PDF, y en una sola hoja o en varias diferentes con el fin de juntarlas posteriormente en un gran póster.

Los enlaces de descarga los encontrareis a continuación:

De momento solo está disponible en inglés, pero para aquellas personas que deseen instalar alguna aplicación desarrollada con Microsoft .NET Compact Framework 3.5 o anterior, se pueden descargar desde ya el paquete redistribuible de .NET Compact Framework 3.5.

El paquete de distribución ocupa cerca de 33 Mb, y además de en inglés, también está disponible en japonés, pero para la versión en español habrá que esperar aún.

Para el que le interese, el enlace de descarga lo encontraréis aquí.

¿Cuántas veces has querido formatear con su color el código de tu aplicación para publicarlo en un blog o simplemente para pegarlo en un documento?.

Pues bien, existe una herramienta online gratuita desarrollada por Jean Claude Manoli, que permite formatear el código escrito en VB, C#, HTML, XML, T-SQL y MSH (nombrado Monad o lo que es lo mismo, PowerShell).

La utilidad es muy sencilla, basta con pegar el código en la caja de texto de la página web, indicar alguna de sus opciones extras, y pulsar el botón "format my code". El formateador hará el resto. :-)

Accedereis a esta herramienta en este enlace.

Publicado por Jorge Serrano | 5 comment(s)
Archivado en: ,

Microsoft ha elaborado una lista de comparaciones de algunas de las versiones de Visual Studio 2008, de todas a excepción de la versión Express Edition.

Se puede acceder a la lista de comparaciones de Visual Studio Team System 2008 en este enlace.

Si lo que queremos es comparar entre Visual Studio 2008 Standar y Visual Studio 2008 Professional, podemos acceder a esta otra lista.

Las comparaciones están realizadas en inglés y creo que ayudará a más de una persona a elegir por que versión de Visual Studio 2008 decidirse.

Publicado por Jorge Serrano | 4 comment(s)
Archivado en:

En esta ocasión, quería comentaros la existencia de una herramienta de nombre Storyboard Designer, una herramienta DSL compuesta de personalizaciones muy interesantes.

La herramienta permite crear un proyecto personalizado de tipo Storyboard, o lo que es lo mismo, generar nuestro "storyboard" de aplicación, algo así como un workflow esquelético de nuestra aplicación o de algunos flujos, procesos o clases de ella.

Al ver esta herramienta, a veces me recuerda a UML (al que por cierto odio), pero he probado esta herramienta y he visto que es muy sencilla de utilizar y se puede usar incluso para documentar aplicaciones y realizar los diagramas de los procesos, aunque hecho en falta muchas más personalizaciones que podrían hacer que esta herramienta fuera más aprovechable. No obstante, me ha gustado mucho la idea.

El caso es que la aplicación, está en fase de desarrollo aún (CTP Noviembre 2007), pero tiene muy buena pinta.

Lo mejor: tenemos a nuestra disposición el código fuente de esta herramienta.

Lo peor: pese a lo los requerimientos necesarios indicados pos su autor, os indico aquí los que yo he tenido que instalar:

El enlace del proyecto lo encontraréis aquí.

LANZAMIENTOS MICROSOFT

Microsoft ha anunciado públicamente el próximo lanzamiento de Windows Server 2008, SQL Server 2008 y Visual Studio 2008.

La inscripción al lanzamiento que tendrá lugar los próximos 26 y 27 de Febrero de 2008 (¡¡¡2 días!!!) ha quedado abierta desde hoy mismo.

Los detalles de inscripción los encontrarás en este enlace, y de forma directa en este otro.

¡No os lo perdáis porque hay cosas que se están preparando para el evento que tienen muy buena pinta!

Microsoft, ha publicado una interesantísima lista de comparaciones entre VB 2005 y VB 2008.

En esta lista se compara a ambos lenguajes y se estudia en esas comparaciones los resultados obtenidos.

Toda esta entrada escrita en inglés es digna de ser leída.

Espero que os parezca tan interesante como a mí.

Podréis acceder a esta información en este enlace.

Más artículos Página siguiente >