Windows Phone & Azure. Shaken, not stirred. : Windows Phone 7, SQL CE

Mejoras de Rendimiento en entornos SQL CE - I

Rafa Serna — Wed, 07 Sep 2011 14:32:00 GMT

Una de las cosas que debemos de tener muy en cuenta a la hora de trabajar con dispositivos móviles, es el rendimiento. Ya sabemos que pronto saldrán, si es que no lo han echo ya móviles con doble procesador y demás, pero no dejamos de necesitar controlar mas nuestro entorno en un dispositivo móvil que en un equipo de sobremesa.

Últimamente a nadie se le escapa que cualquier desarrollador en entornos de escritorio, sencillos, ha (hemos) dejado un poco de lado esta parte de rendimiento, ordenadores con 8 Gb de Ram, 4 núcleos, etc, etc, hacen que el rendimiento este en tu lista de requisitos bastante alejado de las primeras posiciones.

Como he comentado, nos encontramos con otro tipo de entornos y si queremos hacer buenas aplicaciones empresariales para Windows Phone 7 ya no puede estar el rendimiento al fondo de la lista de requisitos, sino mas bien al contrario, si no es la primera será la segunda.

El uso de SQL CE como base de datos relacional en una de nuestras aplicaciones hace que tengamos a parte un elemento mas de saturación de rendimiento, nuestra aplicación y los propios procesos internos que debe de hacer SQL CE. Pero es bastante sencillo seguir una serie de consejos que aplicándolos nos ahorran bastante tiempo de proceso.

Inserción de Datos.

Nuestro amigo el Insert. Esto que voy a comentar es mas de sentido común que de forma de hacerlo especial para ganar rendimiento.

Pongamos por ejemplo el mapeo de esta sencilla tabla.

[Table]

public class Tabla1

{

    [Column(IsPrimaryKey=true, IsDbGenerated=true)]

    public int ID { get; set; }

    [Column]

    public string Nombre { get; set; }

    [Column]

    public string Apellidos { get; set; }

    [Column]

    public string Email { get; set; }

}

Como digo, una sencilla tabla con 4 campos y clave primaria entera auto incremental.

Si realizamos la inserción por ejemplo de 1000 filas, podemos hacerlo básicamente de 3 formas:

1º Utilizando InsertOnSubmit y seguidamente realizar un SubmitChanges

Tabla1 Dato;

using (ContextoDatos Contexto = new ContextoDatos(CadenadeConexion))

{

    for (int i = 0; i < int.Parse(NRegistros.Text); i++)

    {

        Dato = new Tabla1();

        Dato.Nombre = "Nombre " + i.ToString();

        Dato.Apellidos = "Apellidos " + i.ToString();

        Dato.Email = "Email" + i.ToString() + "@live" + i.ToString() + ".com";

        Contexto.Personas1.InsertOnSubmit(Dato);

        Contexto.SubmitChanges();

    }

}

2º Utilizando también el InsertOnSubmit pero dejar el SubmitChanges para el final

Tabla1 Dato;

using (ContextoDatos Contexto = new ContextoDatos(CadenadeConexion))

{

    for (int i = 0; i < int.Parse(NRegistros.Text); i++)

    {

        Dato = new Tabla1();

        Dato.Nombre = "Nombre " + i.ToString();

        Dato.Apellidos = "Apellidos " + i.ToString();

        Dato.Email = "Email" + i.ToString() + "@live" + i.ToString() + ".com";

        Contexto.Personas1.InsertOnSubmit(Dato);

    }

    Contexto.SubmitChanges();

}

3º Usar un elemento que sea IEnumerable, utilizar InsertAllOnSubmit y realizar un SubmitChanges.

List<Tabla1> Datos = new List<Tabla1>();

Tabla1 Dato;

using (ContextoDatos Contexto = new ContextoDatos(CadenadeConexion))

{

    for (int i = 0; i < int.Parse(NRegistros.Text); i++)

    {

        Dato = new Tabla1();

        Dato.Nombre = "Nombre " + i.ToString();

        Dato.Apellidos = "Apellidos " + i.ToString();

        Dato.Email = "Email" + i.ToString() + "@live" + i.ToString() + ".com";

        Datos.Add(Dato);

    }

    Contexto.Personas1.InsertAllOnSubmit(Datos);

    Contexto.SubmitChanges();

}

Como alguna que otra vez he oído decir a alguien, las cosas se pueden hacer mal, o muy mal y en este caso usar el SubmitChanges tras realizar un InsertOnSubmit, es sin lugar a dudas una opción malísima. Obviamente todo depende de que aplicación estemos desarrollando pero, tenemos que tener en cuenta que reflejar físicamente los datos en la base de datos y no mantenerlo en memoria hasta hacer un Submit final, salvo en casos en donde las transacciones de la información sea primordial es totalmente innecesario. Tenemos que tener en cuenta que el móvil solo lo usamos nosotros. :-)

Insertando como decimos 1000 registros en 5 ocasiones diferentes el tiempo en realizar cada operación a sido el siguiente:

	Opción 1	Opción 2	Opción 3
1ª Inserción	28.294 ms	422 ms	529 ms
2ª Inserción	33.778 ms	399 ms	394 ms
3ª Inserción	27.331 ms	392 ms	381 ms
4ª Inserción	25.930 ms	504 ms	568 ms
5ª Inserción	26.876 ms	380 ms	390 ms

Es decir usar los métodos 2 y 3 apenas varia el rendimiento, pero estos son un 97% mas rápidos que la opción 1. Ahí queda eso.

En el siguiente post, ya veremos que realizando dos o tres toques sutiles en la definición de nuestras bases de datos, también podremos ganar mucho tiempo.

Creación visual de tablas para el uso con SQL CE y “Mango”.

Rafa Serna — Mon, 29 Aug 2011 08:51:00 GMT

Este post lo escribí originalmente en mi blog personal el día 03/08/2011.

¿Pero como que creación visual de tablas?, si se nos ha dicho que no, que debemos de picarnos todo el mapeo de nuestras bases de datos para trabajar con el DataContext a mano. Quizás alguna que otra herramienta podría ayudarnos pero poca cosa mas, siempre dependiendo de una base de datos ya existente. ¿No es así?

Pues no, os engañaron, bueno vale: nos engañaron.

Vamos a darles a los chicos de desarrollo de Windows Phone, el margen de la duda y pongamos que simplemente no nos lo han contado así para no liarnos y para no pensar que las cosas están un poquito a medias. Si en el fondo son chicos majos.

Pues SI, si que se puede y además de la manera mas tonta, quizás es que nadie lo ha probado, pero bueno yo creo que es un pequeño truco o apaño, pero mejor que picarnos a mano todo nuestro mapeo, para mi es mas que suficiente.

Para ello simplemente creare una aplicación mínima, y mostrare como se tiene que hacer: Creamos nuestra solución en la cual estará incluido obviamente nuestro proyecto de “Windows Phone Application”, a parte de esto crearemos simplemente para apoyarnos en la herramienta, dentro de nuestra solución (no es esto obligatorio) una biblioteca de clases.

Una vez que tenemos este esquema montado, procedemos a crear un nuevo elemento del tipo “Clases de LINQ to SQL”, fichero del tipo “.dbml” en nuestro proyecto de biblioteca de clases. Una vez creado este elemento procedemos a crear las clases de forma visual en nuestro “Object Relational Designer”.

En este ejemplo crearemos dos clases (Tablas) con una serie de propiedades (Columnas o campos) cada una de ellas. Así mismo también crearemos una asociación entre ambas y una clave secundaria en una de ellas para comprobar que mas o menos toda la funcionalidad que nos permite LINQ to SQL en nuestro Windows Phone, la podemos mapear de forma visual desde aquí. El esquema o mapeo de datos quedaría de la siguiente manera:

Una vez realizado el mapeo de forma visual, debemos de fijarnos que junto a nuestro fichero original “.dbml”, existen 2 ficheros mas, el que define el layout del diseñador y el que nos interesa, el fichero con extensión “.designer.cs”. Este es el fichero que contiene todo el mapeo de datos que hemos creado anteriormente de forma visual y es el fichero que vamos a agregar a nuestro proyecto de “Windows Phone”.

Una vez añadido a nuestro proyecto “principal”, simplemente quitaremos un par de constructores que crea por defecto Visual Studio en el DataContext, que por otra parte son los dos mismos constructores que deberemos de quitar si utilizamos la herramienta SQLMetal para crear nuestro mapeo de datos. Estos constructores son los que nos solicita como parámetros de entrada los objetos del tipo “System.Data.IDbConnection”. No deberemos de olvidarnos de agregar la referencia al ensamblado “System.Data.LINQ”, si queremos que todo esto nos funcione.

Punto y final, ya tenemos nuestro mapeo de datos terminado. Ahora a crear la base de datos y trabajar con ella. La única pega, pues que cada vez que queramos modificar nuestra base de datos deberemos de volver a importar nuestro fichero “.designer.cs” y volver a quitar los dos constructores comentados. Que es eso comparado con el trabajo que llevaría mapear a mano una base de datos nueva que sea un poco compleja.

Y para muestra un botón, aquí os dejo una captura de la estructura de base de datos que nos crea nuestro nuevo DataContext y un ejemplo completo de como hacerlo. Ejemplo de como poder hacerlo:

SQL CE - Un “DataContext” para gobernarlos a todos.

Rafa Serna — Mon, 22 Aug 2011 06:53:00 GMT

Este Post, originalmente lo escribí para mi blog personal, el día 15/07/2011

Lo primero que debemos de conocer es como se va a organizar la estructura de los datos en nuestras BBDD, gestionadas por “Mango”, para ello lo primero que debemos de conocer es el funcionamiento en profundidad de LINQ to SQL. ¿Porque LINQ to SQL?, por que será la única forma de interactuar con SQL CE, ya que no existirán las conexiones directas contra las bases de datos.

Según MSDN en sus librerías para Windows Phone “LINQ to SQL proporciona un enfoque orientado a objetos para trabajar con datos y contar con un modelo de objetos en tiempo de ejecución.” o dicho de otra manera “el modelo de datos de una base de datos relacional se asigna a un modelo de objetos expresado en el lenguaje del programador”.

Para realizar toda esta magia de poder manejar los datos como objetos, se utiliza un objeto principal denominado DataContext, que, otra vez según MSDN “actúa como un proxy para la base de datos local”. Este objeto esta recogido en el espacio de nombres System.Data.Linq.DataContext.

Para aproximarnos a su funcionamiento en los entornos de Windows Phone “Mango”, podremos seguir la siente imagen:

Una vez que conocemos que todo gira en torno al DataContext, deberíamos de tener en cuenta las diferencias entre el DataContext utilizado en nuestros entornos móviles y el DataContext utilizado en entornos de escritorio.

Lo primero que debemos saber es que no están soportados todos los tipos y clases soportados en el namespace System.Data.Linq y que los que están soportados lo están de forma parcial.
Como ya comente en la entrada preliminar, no esta soportado la utilización del lenguaje Transact-SQL.
Los objetos de datos de ADO.NET, tampoco están soportados, como por ejemplo el objeto DataReader. Todo, absolutamente todo se utiliza como una colección de objetos del tipo especificado por el DataContext.
Los formatos binary de datos tampoco están soportados. Mejor dicho si lo están pero no de forma directa, se deberán de crear tipos propios y parsearlos contra los tipos binarios de nuestra base de datos.
En este caso LINQ to SQL solo funciona con SQL CE.

Para conocer mas en profundidad que o que no esta soportado en LINQ to SQL para Windows Phone, debéis visitar como no MSDN.

Creación del DataContext.

Como he comentado lo primero es la creación del DataContext, para ello lo primero que debemos de hacer es añadir la referencia del ensamblado System.Data.Linq. Ahora creamos la clase del tipo DataContext.

public class ContextodeDatos : DataContext

{

    public ContextodeDatos(string CadenaConexion) : base(CadenaConexion)

    {

    }

}

El DataContext es como venimos diciendo todo el tiempo, el que se encarga de manejar los datos en si, para ello debemos de tener la referencia a los objetos (datos), que vamos a utilizar. Con lo que previamente al paso de crear el contexto de datos, deberíamos de haber creado la clase que mapea los datos, es decir el objeto puente entre los datos reales contenidos en la BBDD y LINQ to SQL. Estos objetos se denominan comúnmente objetos POCO (Plain Old CLR Object)

En este ejemplo vamos a tener una base de datos con 2 tablas, Autores y Libros, y obviamente estas dos tablas tendrán sus correspondientes campos. El esquema de ambas es el que se detalla a continuación.

Como hemos comentado deberemos de crear una serie de clases que mapeen a cada una de las tablas “físicas” de la BBDD, comenzaremos por crear la primera de ellas sobre la tabla “Autores”. Para guiarnos de una forma sencilla las denominaremos como las tablas a las que mapean.

No debemos de olvidarnos de añadir en el uses de nuestro fichero la referencia al namespace System.Data.Linq.Mapping.

[Table(Name="Autores")]

public class Autor

{

    [Column(IsPrimaryKey=true, IsDbGenerated=true)]

    public int ID { get; set; }

 

    [Column]

    public string Nombre { get; set; }

 

    [Column]

    public string Apellidos { get; set; }

 

    [Column]

    public string Pais { get; set; }

}

Tras crear la clase Autores, crearemos la clase Libros.

[Table(Name="Libros")]

public class Libro

{

    [Column(IsPrimaryKey=true)]

    public string ISBN { get; set; }

 

    [Column]

    public string Titulo { get; set; }

 

    [Column]

    public decimal Precio { get; set; }

 

    [Column]

    public string Editorial { get; set; }

 

    [Column]

    public string Autor { get; set; }

 

    [Column]

    public string Idioma { get; set; }

}

Lo primero de lo que nos damos cuenta es de los atributos utilizados en la creación de ambas clases. Podemos ver aquí la lista completa de los atributos que se pueden utilizar a la hora de mapear los datos en LINQ to SQL. Tenemos que tener en cuenta que no todos los atributos son soportados. En nuestro caso solo hemos utilizados dos de forma muy sencilla:

[Table]: Atributo para indicar que la clase mapea una tabla de datos. Además hemos utilizado una propiedad de este atributo (la única posible así mismo), denominada “Name”, por la que indicamos el nombre de la tabla dentro de la BBDD.

[Column]: Atributo para indicar que el miembro de la clase se mapea a una columna de la tabla, a un campo de la tabla. En este caso hemos utilizado dos propiedades de este atributo:

IsPrimaryKey: Por la que indicamos que columna o columnas forman parte de la clave primaria de la tabla.
IsDbGenerated: Con esta otra propiedad indicamos que columna es auto-generada por la base de datos. En este caso que la columna es auto incremental.

Como podemos observar el mapeo de las bases de datos es algo bastante latoso, en este caso tenemos simplemente dos tablas muy sencillas dentro de una base de datos bastante normalita, este tema en un entorno real puede convertirse en algo bastante lioso. No existen aun herramientas de modelado o de mapeo automático para este tipo de clases, de forma nativa con Visual Studio pero si que existen herramientas de terceros que pueden ayudarnos a realizar estas tareas de una manera mas visual y mas cómoda. En posteriores post hablare de ellas.

Bueno pues seguimos con nuestro contexto. Anteriormente creamos la clase del tipo DataContext, ahora lo único que debemos de hacer es referenciar nuestros mapeos de las tablas creadas dentro de ese contexto de datos.

public class ContextoDeDatos : DataContext

{

    public ContextoDeDatos(string CadenaConexion) : base(CadenaConexion)

    {

    }

 

    public Table Autores

    {

        get { return this.GetTable(); }

    }

 

    public Table Libros

    {

        get { return this.GetTable(); }

    }

}

Bien, una vez con todo esto lo unico que nos queda es interactuar con nuestra base de datos, para ello lo que haremos es comprobar a la hora de inicializar nuestra aplicacion, si la base de datos existe y si esta no existe, la crearemos.

// Constructor

public MainPage()

{

    InitializeComponent();

 

    string ConnectionString = "Data Source='isostore:/Pruebas.sdf'";

 

    using (ContextoDeDatos Contexto = new ContextoDeDatos(ConnectionString))

    {

        if (Contexto.DatabaseExists() == false)

        {

            Contexto.CreateDatabase();

        }

    }

}

Lo primero que nos debe de resultar un tanto extraño es el formato de la cadena de conexión utilizada, a grandes rasgos le estamos diciendo a nuestra aplicación que la base de datos se encuentra dentro del Isolated Storage de la propia aplicación y que en la ruta raíz de ese Isolated Storage el fichero se llama Pruebas, con la extensión común a SQL Server Ce “.sdf”.

De momento lo dejamos aquí, en el próximo post, hablare de donde exactamente se encuentra nuestra base de datos, como podemos acceder a ella de forma remota, para comprobarla y demás, así como un repaso de las herramientas de terceros que nos pueden facilitarnos un poco la vida en la creación del mapeo de nuestras bases de datos.

En el fichero superior podéis encontrar el código fuente de la pequeña aplicación de ejemplo en donde se utiliza todo lo explicado anteriormente.

Nota: “Ash nazg durbatulûk, ash nazg gimbatul... Ash nazg thrakatulûk agh burzum-ishi krimpatul” es el texto completo escrito en la lengua de Mordor, el cual estaba inscrito en el Anillo que portó, primero, Bilbo Bolsón y luego Frodo Bolsón, propiedad de Sauron, cuya traducción es “Un anillo para gobernarlos a todos, un Anillo para encontrarlos, un Anillo para atraerlos a todos y atarlos en las Tinieblas”.