Usando Visual Studio, LINQPad 4 y NHibernate Profile (versión paso a paso)
Introducción
La semana pasada, mi compañero de trabajo y sufrimientos, Luis Ruiz Pavón, escribió una interesantísima entrada sobre cómo utilizar LINQPad 4 y NHibernate para probar consultas LINQ y resolver posibles problemas de rendimiento, cuellos de botella, etc., sin tener que hacer grandes alardes de programación… es decir, sin utilizar Visual Studio.
En mi caso, voy a preparar una entrada variante y complementaria de la de Luis pero enfocándome en lo que sería un pequeño ejemplo paso a paso de cómo llevar a cabo esta tarea utilizando levemente Visual Studio para aquellos que se encuentren un poco perdidos en la utilización de LINQPad 4 y NHibernate Profiler tal y como apuntaba Luis.
Preparando el modelo
Lo primero de todo, vamos a crear un proyecto de tipo Class Library en C# por ejemplo, al que le he puesto el nombre de NHibernateTest y en el que agregaremos una clase de nombre Exployee y con los siguientes campos:
1: namespace NHibernateTest
2: {
3:
4: using System;
5:
6:
7: public class Employee
8: {
9:
10: public virtual Guid Id { get; set; }
11: public virtual string Name { get; set; }
12: public virtual string Surname { get; set; }
13: public virtual string Address { get; set; }
14: public virtual string City { get; set; }
15: public virtual string Country { get; set; }
16:
17: } // Employee
18:
19: } // NHibernateTest
A continuación, compilaremos nuestro proyecto para ver que todo está bien.
Una vez hecho esto, nos olvidaremos ya de Visual Studio.
Pensemos por lo tanto, en que hemos preparado un proyecto con los objetos de dominio o similar.
Sin embargo, nos gustaría poder “jugar” con ellos introduciendo datos o haciendo algunas operaciones básicas o genéricas con NHibernate.
Crear un proyecto de consola o similar es una alternativa, pero nos obligaría a abrir Visual Studio y trastear, cuando en realidad, lo que queremos, es hacer algo más ágil, rápido y sencillo.
Preparando LINQPad 4
Vamos a ejecutar por lo tanto LINQPad 4.
Lo primero que haremos será modificar la propiedad Language a C# Statements.
Una vez hecho esto, si queremos, podemos establecer una conexión con nuestra base de datos.
En concreto, tengo una base de datos en SQL SERVER a la que le he puesto el nombre de TESTS, y que tiene una tabla de nombre Employees con los campos indicados en la clase de C# que vimos anteriormente:
Sólo de modo opcional y si quisiéramos establecer una conexión en LINQPad 4 con nuestra fuente de datos, haríamos clic en la opción Add connection de la aplicación:
Probaríamos la conexión y veremos que todo es correcto. Pero en este caso, este último paso lo vamos a obviar.
Fichero de configuración de NHibernate en lugar de utilizar la conexión con LINQPad 4
En mi caso sin embargo, voy a tirar de ficheros de configuración.
Así que para establecer la conexión con nuestra fuente de datos, voy a crear un archivo de configuración llamado sqlserver.hibernate.cfg.xml dentro del cual he agregado la siguiente configuración:
1: <?xml version="1.0" encoding="utf-8" ?>
2: <configuration>
3: <configSections>
4: <section name="hibernate-configuration" type="NHibernate.Cfg.ConfigurationSectionHandler, NHibernate"/>
5: </configSections>
6: <hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
7: <session-factory>
8: <property name="dialect">NHibernate.Dialect.MsSql2008Dialect</property>
9: <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
10: <property name="connection.connection_string">Data Source=P-JOSE8MSSQLSERVER2012;
11: Initial Catalog=TESTS;Integrated Security=True</property>
12: </session-factory>
13: </hibernate-configuration>
14: </configuration>
Recapitulando, hemos dejado preparado LINQPad 4 y hemos creado una biblioteca de clases en Visual Studio donde hemos creado nuestra clase Employee con sus campos.
Tenemos una base de datos de prueba con una tabla Employees con los campos correspondientes, y por último, hemos creado un archivo de configuración de NHibernate para establecer la conexión con nuestra fuente de datos.
Creando el archivo de mapeo con la entidad Employee
El siguiente paso será el de preparar el archivo de mapeo de nuestra entidad Employee para que NHibernate interprete correctamente sus campos y pueda trabajar con ella sin problemas.
Existen otras formas de llevar a cabo esto, pero aquí y para probar todo, vamos a hacerlo así.
El archivo de mapeo se llamará Employee.hbm.xml, y su contenido queda de la siguiente manera:
1: <?xml version="1.0" encoding="utf-8" ?>
2: <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
3: assembly="NHibernateTest"
4: namespace="NHibernateTest">
5: <class name="Employee" table="Employees">
6: <id name="Id">
7: <generator class="guid.comb" />
8: </id>
9: <property name="Name" not-null="true" />
10: <property name="Surname" />
11: <property name="Address" />
12: <property name="City" />
13: <property name="Country" />
14: </class>
15: </hibernate-mapping>
Vuelta a LINQPad 4, agregando ensamblados y namespaces
Para completar todo el proceso, vamos a agregar algunos ensamblados y namespaces a LINQPad 4 para que cuando agreguemos el código de ejecución, pueda localizar e interpretar las instrucciones de código que vamos a ejecutar de forma correcta.
Lo primero que debemos tener en la herramienta NHibernate Profiler que nos va a permitir analizar las instrucciones que lanzamos contra NHibernate.
Por otro lado, en LINQPad 4 vamos a pulsar la tecla F4 que nos permite abrir la ventana para agregar referencias, ensamblados y namespaces.
Nos situaremos en la solapa Additional References.
Los ensamblados a agregar son estos cuatro:
- HibernatingRhinos.Profiler.Appender.dll
- Iesi.Collections.dll
- NHibernate.dll
- NHibernateTest.dll
Dentro de la carpeta en la que tenemos nuestra herramienta de profiling encontraremos un ensamblado de nombre HibernatingRhinos.Profiler.Appender.dll que deberemos agregar en las referencias adicionales de LINQPad 4.
También deberemos agregar las librerías Iesi.Collections.dll y NHibernate.dll que encontraremos en la carpeta de ensamblados de NHibernate.
Y finalmente agregaremos el ensamblado que creamos con Visual Studio al principio del todo.
Para concluir, iremos a la solapa Additional Namespace Imports y agregaremos tres namespaces:
- NHibernate
- NHibernate.Cfg
- NHibernateTest
Bastará con poner cada uno de los nombres de los namespaces ahí uno debajo del anterior.
LINQPad 4 ya se encargará de hacer el correspondiente using por nosotros.
Escribiendo el código a ejecutar en LINQPad 4
Ya estamos prácticamente concluyendo.
El último paso es escribir nuestro código y ejecutarlo.
Para ello, vamos a escribir el siguiente código:
1: HibernatingRhinos.Profiler.Appender.NHibernate.NHibernateProfiler.Initialize();
2:
3: ISessionFactory sessionFactory = new Configuration().
4: Configure(@"C:Tempsqlserver.hibernate.cfg.xml").
5: AddFile(@"C:TempEmployee.hbm.xml").BuildSessionFactory();
6: using (ISession session = sessionFactory.OpenSession())
7: {
8: using (ITransaction transaction = session.BeginTransaction())
9: {
10: Employee employee = new Employee();
11: employee.Name = "Pedrito";
12: employee.Surname = "Gómez Sánchez";
13: employee.Address = "Calle Mayor, 1";
14: employee.City = "Burgos";
15: employee.Country = "Spain";
16: session.Save(employee);
17: transaction.Commit();
18: session.Close();
19: }
20: }
Este ejemplo, cargará el archivo de configuración de NHibernate para establecer la conexión con NHibernate y el archivo de mapeo de la entidad Employee.
Finalmente agregaré un nuevo empleado a la base de datos con los datos que hemos agregado aquí.
Podríamos haber hecho un bucle para agregar un conjunto de empleados a modo de ejemplo o cualquier otra cosa, pero sirva este ejemplo para mostrar cómo escribir datos en una tabla utilizando NHibernate y sin apenas utilizar Visual Studio.
El caso es que para ejecutar nuestro código, bastará con pulsar el botón de ejecución o pulsar la tecla F5.
Si la ejecución es correcta, veremos un mensaje en la parte inferior de la aplicación LINQPad 4 que indica algo así como Query successful.
Analizando NHibernate Profiler
Adicionalmente y con ayuda del profiler, podemos obtener información valiosa a la hora de ejecutar nuestras instrucciones.
Si comprobamos los datos en SQL Server, veremos que estos están correctamente persistidos.
(Nota: también podemos ver los datos persistidos desde LINQPad 4 si hemos establecido previamente una conexión con el modelo de datos como se apuntaba al principio, lo cuál nos evitará incluso la tarea de irnos a SQL Server Management Studio).
Tal y como decía Luis en su entrada, estas prácticas nos pueden ahorrar mucho tiempo y quebraderos de cabeza.
Podemos crear y ejecutar instrucciones LINQ o podemos incluso probar determinados comportamientos y ejecuciones en nuestro código sin tener la necesidad de abrir Visual Studio para ello.
Espero que le resulte de utilidad a más gente.
One Responseso far
Y… algo similar pero con EF? 🙂