MSDN Code Gallery


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.

LINQ to Entities y Visual Basic 2008 – n-capas – Parte 4


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.

LINQ to Entities y Visual Basic 2008 – n-capas – Parte 3


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.

GRATIS :: eLearning :: ¿Que hay de nuevo en SQL Server 2008?


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.

Navegando por el código de un proyecto en Visual Studio 2008


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.


Implantar un proyecto Web con Visual Studio 2008 nunca fue tan fácil


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.

Comparación completa de las versiones de Visual Studio 2008


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:


LINQ to Entities y Visual Basic 2008 – Parte 2

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?).

LINQ to Entities y Visual Basic 2008 – Parte 1

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):


Proyecto piloto de los Foros para enviar bugs sobre VB


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.