miércoles, 30 de noviembre de 2016

Tutorial Xamarin con Data Binding

Cuando uno mira ejemplos de uso de ciertas tecnologías, normalmente suelen mostrar la forma más sencilla de lograr el objetivo, pero sin reparar en la creación de una arquitectura base que después se pueda considerar válida para una aplicación "productiva". 

En este tutorial voy a mostrar cómo crear una simple aplicación (un conversor de medidas), pero utilizando el patrón Model-View-ViewModel (MVVM). 

Comencemos con filosofía. ¿Por qué quiero hacer algo así? La respuesta es porque si uso un patrón que define cómo se intercambian los datos entre la pantalla y el modelo podemos, entre otras cosas: generar pruebas, intercambiar modelos sin tener que reemplazar las vistas, utilizar métodos que pueden ser comunes a todas las pantallas, simplificar la creación de nuevas pantallas y, si otra persona conoce el patrón, le resultará más fácil respetarlo.

Entonces, si quisiera crear una aplicación de Android con Xamarin y Visual Studio que convierta un valor de kilómetros dado a millas, el procedimiento sería:

  • Crear una aplicación usando el template Android à Blank App (Android)
  • Modificar el layout para que contenga un textBox para ingresar los kilómetros
  • Un botón para hacer la conversión
  • Y un textView para mostrar la cantidad de millas resultantes
  • Y dentro del código del click del botón:

           o Buscamos el textbox de kilómetros y obtenemos el valor
           o Hacemos la conversión
           o Buscamos el textview de las millas y seteamos el dato


Bien, esto es sencillo y, ¡tiene que serlo! Pero veamos otra forma que me permita generarle pruebas, para hacer que funcione en distintos dispositivos (para eso usamos Xamarin) o, simplemente que permita extender las posibilidades de la aplicación.

Como dijo Jack el destripador, vamos por partes. El patrón MVVM plantea la separación de la lógica en un modelo, una vista y un viewmodel que interactúe entre los dos. Por otro lado, este patrón suele implementarse en conjunto con la técnica de two-way binding que le permite a la vista refrescarse cuando cambia el modelo y al modelo cuando cambia la vista. Existen muchos frameworks que utilizan estas técnicas, pero creo que el más nombrado últimamente es Angular (tanto JS como Angular2).

¡Pero construir eso va a ser muy complejo! No creo que sea para tanto, veamos los pasos:
  • Crear un proyecto usando el template Cross-Platform à Blank App (Xamarin.Forms Shared)
  • Crear un modelo que tenga los kilómetros, las millas y el método de conversión
  • Crear una vista de XAML que tenga un textbox (entry) para ingresar los kilómetros
  • Y un label para mostrar la cantidad de millas resultantes
  • Crear un ViewModel que pase el dato de los kilómetros al modelo (conversor), que     ejecute la conversión y avise, en este caso a la vista, que cambió la propiedad millas
  • Por último, vinculamos la vista con el ViewModel


Como dice Zamba: ¡Me aburro! Entonces, pasemos a la construcción del ejemplo:

Pueden encontrar el código completo en:

Creamos el proyecto:



Luego va a ofrecer la conexión con un equipo Mac para poder compilar para iPhone y, como en mi caso no tengo, voy a presionar el botón close. 





En esta pc, tampoco tengo el SDK del Universal Windows Plataform (que permite compilar para Xbox entre otros)





Vamos a probar que todo funcione como corresponde, seleccionado el dispositivo para la prueba y ejecutando el proyecto. En este caso, en el emulador con 4.5'' de pantalla y Android  versión 4.4:


Y luego debería mostrar la siguiente pantalla:



OK, comenzamos el desarrollo. Primero, dentro del proyecto Shared crearemos la carpeta Shared y dentro, las carpetas Models, Views y ViewModels. Este es solo un ejemplo, hay gente que prefiere tener la vista y el ViewModel en la misma carpeta, pero yo lo encuentro más claro de esta manera. 
La estructura debería quedar así:




Creamos la clase del modelo:



Creamos la vista. En este caso crearemos un Forms Xaml Page. Recordemos que la idea es tener separada la lógica de la presentación (la vista en Xaml) de la lógica que habilita o deshabilita controles, cambia colores, muestra u oculta secciones de la pantalla (el ViewModel):



Agregamos los controles:



Creamos la clase ConversorViewModel.cs, en la cual agregaremos las referencias a System.ComponentModel que nos permitirán usar la Interfaz INotifyPropertyChanged que brinda la posibilidad de que la vista se suscriba a los cambios en el ViewModel. Además, agregamos una referencia a nuestro modelo:



Y luego incorporamos las propiedades que serán utilizadas en la vista:



Buscamos el ConversorPage.xaml.cs y seteamos el BindingContext con el ViewModel:





Por último, le diremos a la aplicación que use la nueva pantalla que hemos creado, seteando el MainPage de la clase App del proyecto shared con una nueva instancia del ConversorPage:



Finalmente, lo probamos:





Esta solución tiene varios puntos a favor como, por ejemplo:
el ViewModel es el encargado de la trasformación del string proveniente de la pantalla al double que necesita el modelo.
Además, si quiero que cuando me ingresen un número negativo se ponga en rojo el valor de las millas, se puede resolver por medio de un método en el ViewModel, de esta manera logramos que se pueda testear.
Obviamente, cambiar colores se podría hacer directamente en la pantalla, pero hacerlo en el ViewModel lo hace explícito y no hay que recorrer el Xaml de la vista para encontrarlo.
Por otro lado, aunque se genera un acoplamiento entre la vista con el ViewModel y entre el ViewModel con el modelo, no hay acoplamiento entre la vista y el modelo. 


Algunos links para continuar investigando el tema:

Autor:
Marcelo Mosquera
.NET Architect

miércoles, 21 de septiembre de 2016

Automatic Software Repair

Automatic Software Repair es un área de investigación del desarrollo de software que comenzó a utilizarse alrededor del año 2000. Es una técnica que tiene como función arreglar bugs de forma automática; es decir sin intervención humana.

Para poder comprender de qué se trata, tenemos que partir de los conceptos fundamentales utilizados en esta rama de la investigación de software: 

En primer lugar, cabe destacar que todo programa en ejecución tiene comportamientos esperados y no esperados, pero también hay un sujeto implícito que es el que observa que estos comportamientos sean de esa manera. El mismo puede ser un QA (un humano) o también puede ser una especificación (conjunto de comportamientos esperados explícitos, ya sea los formulados en una batería de test, o los implícitos, como ser un programa que no puede “crashear” bajo ningún input). 

Otro concepto importante y muy ligado a las especificaciones, es el de oráculos. Cuando hablamos de ellos, nos referimos a “artefactos” que nos indican si una ejecución es correcta o no. Como vemos, los dos términos se asemejan entre sí, ya que hablan de comportamientos esperados; entonces, ¿dónde radica la diferencia? En que la especificación suele contener información no funcional (tipos de input, rangos de entrada) mientras que los oráculos tienen instancias concretas de validación. De esta manera, dentro de Automatic Software Repair tenemos dos oráculos: los de bug y los de regresión. Los de Bug nos indican que existe un error y que hay que empezar nuestro proceso de reparación, mientras que los de regresión nos indican que tras este proceso introdujimos algún error. 

Una de las claves de Automatic Software Repair, es que para realizar un proceso de reparación automática, debe realizarse en una clase de bugs. Este conjunto de errores puede ser de acuerdo a su causa raíz, a sus síntomas o a su reparación. 

Luego, se deberían preparar buenos oráculos, tanto de bug como de regresión, para continuar con la ejecución de algoritmos de reparación que completen el proceso. Estos algoritmos, nos indican adonde tenemos que probar nuestras reparaciones automáticas, y se pueden clasificar en dos grandes “familias”. 

La primera de ellas es la reparación en tiempo real, que se basa en el cambio de estado del programa para lograr un comportamiento adecuado. No se refiere a cambiar el código, sino a la configuración o el input del mismo. 

El oráculo de bug más frecuentemente utilizado en esta reparación es un “crash” o una invariante en el sistema. Para reparar estos estados hay algunos estudios basados en la redundancia, que indican que en un programa hay “varias maneras de hacer lo mismo”. 

Así es como hay estudios para escapar de loops infinitos, para modificar un input por uno esperado dentro del rango, o para darle al programa un objeto default para no “crashear” ante un Null Pointer Exception. 

La otra familia es la generación automática de parches, en donde, a diferencia de la reparación en tiempo real, se cambia el código del programa para repararlo automáticamente. 

En la mayoría de estos estudios, el oráculo de bug es un test case que falla, mientras que un oráculo de regresión es la batería de test asociada a la aplicación que hay que probar. 

En este tipo de reparaciones, llamadas behavior (comportamientos), uno de los estudios más conocidos se basa en “algoritmos de mutación”. Para estos, la solución está en el código: si quitás una línea de código, quizá solucionas un bug; si añadís una, podrías llegar a solucionar un error y, si modificas una línea, también podrías solucionar un bug. ¿Pero cómo se llega a esta conclusión? Con algoritmos que seleccionan y encuentran soluciones, denominados parches.

A pesar de que ya existen gran cantidad de respuestas, dentro de esta rama de investigación, aún quedan algunas preguntas por responder: ¿qué pasa cuando la solución que da el programa no es la correcta? o ¿qué ocurre cuando no se encuentran algoritmos que puedan solucionar el programa? Y esto plantea un nuevo desafío: que un programa pueda reparar un bug, subir un commit y que las personas puedan aprobarlo o no. 

Autor:
Gustavo Lamy Cobarrubia
QA & Testing Specialist

miércoles, 7 de septiembre de 2016

Hoy por mí, mañana por ti... ¿Por qué ser prolijos al escribir código?

¡Hola! Hoy quería hacer foco en un tema que refleja la calidad de las soluciones que desarrollamos como parte de nuestro trabajo. No, no voy a hablar de Testing como la última vez, sino de desarrollo de software.

Cuando hablamos de calidad, no sólo lo hacemos pensando en que un sistema funcione correctamente, sin bugs, sin problemas de performance, con un buen look & feel, cumpliendo con los requerimientos de nuestro cliente, etc. Cuando hablamos de calidad, también podemos referirnos al código fuente, es decir, a aquello que no se ve pero está allí presente, y que es lo que hace que los sistemas puedan funcionar bien, o no tanto…

Hoy por mí

En primer lugar, deberíamos generar código de calidad pensando en que luego es uno mismo quien debe leer, mantener y evolucionar constantemente el mismo a lo largo del proyecto. Difícilmente algo que desarrollemos pueda mantenerse aislado del resto de los componentes de la solución o, una vez listo, no tengamos que volver a modificarlo nunca más.

El primer y principal punto a considerar entonces, es generar el código lo suficientemente claro, ordenado y prolijo, como para que nosotros mismos podamos entenderlo pasados unos días, unas semanas, o unos requerimientos.

Dentro de los aspectos más importantes que debemos tener en cuenta a la hora de escribir buen código fuente, podemos mencionar:

Evitar la duplicación de código, ya sean líneas, bloques completos, métodos y/o clases.

Mantener el código simple, evitando la complejidad innecesaria.

Asignar nombres claros y precisos a las clases, variables, métodos y propiedades. Definir una forma de nombrarlos y luego mantenerla consistente a lo largo de todo el desarrollo.

Comentar nuestro código fuente responsablemente, evitando aquellos comentarios innecesarios que no añadan nada valioso y poniendo sólo aquellos que realmente aporten algo de valor. Además, hay que recordar que la primera documentación del código, debe ser el código mismo. Si logramos que el código sea autodocumentado, sólo deberemos utilizar comentarios en casos particulares o con alguna lógica compleja que deba detallarse.

Evitar construir métodos y/o clases muy largas, o como decimos en la jerga, kilométricas. Esto generalmente suele ser un indicio de un mal diseño técnico previo.

No construir funciones “por las dudas”. Si algo no va a ser usado, es mejor no construirlo. Por otro lado, siguiendo la misma línea, si estamos haciendo mantenimiento de código y vamos a pasar a desuso un bloque de código, es preferible eliminarlo en vez de comentarlo. Si en un futuro lo volvemos a necesitar, podemos obtenerlo del historial de cambios del repositorio de código fuente que estemos usando (hoy en día no hay excusas para trabajar sin uno de ellos).

No abusar de la herencia. Si bien es un mecanismo potente, un mal uso de la misma sólo hace que la solución sea más compleja y difícil de interpretar. Además, es importante no confundir “herencia” con “agregación” a la hora de compartir y dividir responsabilidades funcionales.

Seleccionar los patrones de diseño que realmente nos van a aportar valor a la solución y nos permitirán lograr un diseño más flexible y preciso. Es un error muy común creer que agregando más patrones de diseño la solución va a ser mejor; por el contrario, sólo la hacen más compleja y difícil de mantener.

Evitar las “God Classes”, es decir, esas estructuras que hacen de todo un poco, ya que termina siendo muy engorroso poder modificarlas debido a que su nivel de acoplamiento termina siendo muy alto.

No diseñar firmas de métodos con una gran cantidad de parámetros, ya que agregar o quitar uno de ellos terminará siendo un dolor de cabeza importante, más allá de que logremos volver a hacer compilar la solución. Si tenemos un método que recibe muchos parámetros, podemos preguntarnos si realmente son necesarios o si deberíamos dividir la funcionalidad en dos o más partes. En el caso de que realmente los necesitemos, vayamos por el enfoque de utilizar un DTO en vez de pasar los parámetros individualmente, ya que las modificaciones serán mucho más fáciles de esta forma.

Y la lista continúa… Lo ideal es, más allá de las reglas generales, consultar cuáles son las buenas prácticas particulares que existen para el lenguaje y/o plataforma que estemos utilizando, e implementarlas como parte de la solución.

Mañana por ti

De la forma en la que hoy trabajamos desarrollando software, es muy poco probable que lo hagamos solos, aislados, sin un equipo al lado nuestro participando del mismo proyecto. Por eso, el segundo punto a tener en cuenta es que, además de que nosotros podamos entender nuestro propio código, este tiene que poder ser comprendido por el resto de las personas que forman parte del grupo de trabajo.

Difícilmente podamos lograr una solución integral con un buen estándar de calidad, si no podemos interpretar lo que nuestro compañero quiso codificar. No sólo porque deberemos integrarnos con lo que otros han desarrollado, sino porque además seguramente debamos modificar, extender y/o corregir bugs en código que no es nuestro y, si no lo podemos entender correctamente, es de esperar que no podamos resolver de manera eficiente lo que se nos pida.

Lo bueno es que para poder lograr esto, existen unas series de reglas que, si todos los miembros que formamos parte del equipo del proyecto respetamos, nos permitirán generar un código más homogéneo y de mayor calidad:

Es necesario contar con estándares de codificación definidos, aprobados, aceptados y conocidos por todas las personas que trabajamos en el mismo equipo. Estos pueden ser distintos en cada equipo, o ser definidos de manera global por un área técnica de la empresa, como sucede en el caso de Baufest.

El proyecto debe estar coordinado técnicamente por un Arquitecto o Technical Leader, que deberá velar por la correcta aplicación de los estándares adoptados. Una forma de garantizar esto, es mediante los code reviews.

Además, el código del proyecto debe estar fundado sobre una arquitectura diseñada para satisfacer los requerimientos planteados por el cliente. Sin una arquitectura de base, será muy difícil mantener el código ordenado y prolijo.

Cuando ingresa una nueva persona al equipo, lo ideal es que antes de ponerse a leer los requerimientos funcionales que luego deberá construir, primero se centre en conocer y adoptar los estándares de codificación y trabajo que se están usando en el proyecto.

Se deberá contar con una herramienta de análisis de código que permita analizar el nivel de adopción de los estándares. Es un complemento a los code reviews, pero mucho más potente, ya que permite realizar análisis completos en toda la solución y obtener métricas y reportes precisos sobre los puntos a mejorar. 

En Baufest, por ejemplo, para los proyectos de .Net contamos con SonarQube, integrado a Jenkins. Por lo que si el proyecto está correctamente configurado con integración continua, podremos acceder a estas métricas fácilmente, las cuales se actualizarán con cada checkin que hagamos.

Y... mañana por mí también

Y finalmente… ¿a quién no le ha pasado de volver a un determinado proyecto en el que estuvo hace un par de años atrás? ¿A quién no lo han llamado las personas que luego tomaron ese proyecto preguntándole acerca de algo desarrollado, pidiéndole una mano para implementar una nueva funcionalidad?

Es más común de lo que parece y, por ello, hay que estar siempre preparado. Más allá de pensar en que el código pueda ser entendido por uno mismo unos días después de haberlo escrito, o por el resto del equipo durante el proyecto, hay que pensar qué pasaría si dentro de unos años es necesario retomarlo, ya sea que estemos en el nuevo equipo o no.
Por ello, cuando generemos código, no sólo debe verse bonito, sino además, tiene que ser fácilmente entendible, tiene que estar documentado, organizado, seguir un patrón de diseño y estar asociado a estándares de programación más globales, que permitan al nuevo equipo poder entender rápidamente qué se quiso hacer y cómo.

Además, generar código de calidad hace que las aplicaciones se comporten de forma más predecible, tengan menos tasa de errores, sean más fáciles de mantener y evolucionar y, por otro lado, nos potencian como profesionales, ya que no sólo estaremos generando código, sino que lo estaremos generando bien.

Recuerden, ser prolijos al generar código no sólo nos ayudará a nosotros mismos, sino que además, ayudará a otras personas a entender qué quisimos hacer cuando escribimos esas líneas.

Bueno, es todo por hoy. Les dejo un cierre con un poco de humor referido al tema… 

Fuente: http://www.codecomics.com/

¡Hasta la próxima!

Ing. Ariel Martín Bensussán
.Net Practice Manager

miércoles, 24 de agosto de 2016

¿Cómo serializar una base SQL de Azure con Visual Studio?

Este artículo indica cómo podemos serializar una base de datos de SQL Server que se encuentra en Azure con Visual Studio y sus ventajas. Se complementa con el documento: Cómo serializar una base SQL con Visual Studio  

Para serializar una base SQL que se encuentra en Azure con Visual Studio hay algunos pasos extras que deberemos realizar. Éstos, se centran en asegurar la conexión desde nuestra máquina local a Azure. 

Deberemos:

1. Azure: abrir un puerto desde el portal de administración de Azure
2. Azure: habilitar el acceso a través del Firewall
3. SQL Server Azure: verificar que el protocolo TCP está habilitado
4. SQL Server Azure: configurar usuario
5. Visual Studio local: conectar remotamente a SQL Azure

1. Azure: abrir un puerto desde el portal de administración de Azure

Para poder abrir un puerto desde la máquina virtual de Azure debemos crear un "endpoint",  concepto utilizado para dirigir y controlar el tráfico de ingreso a la máquina virtual.
Luego, ingresamos a nuestra máquina virtual Azure, dentro de la consola de administración de Windows Azure,seleccionamos la "Virtual Machine" en la cual estableceremos el endpoint y hacemos clic en el item: "ENDPOINTS".


Allí vemos que ya hay dos endpoints previamente creados. Uno es para el funcionamiento de PowerShell y el otro es para permitir el acceso remoto. Su generación fue automática cuando creamos la máquina virtual. Para agregar nuestro endpoint hacemos clic en Add:


Se abrirá la siguiente ventana en la cual confirmaremos que queremos crear un endpoint de tipo "stand-alone". La opción “Add an endpoint to an existing load-balanced set” no es relevante para nuestro objetivo: establecer una conexión desde una máquina local a un servidor SQL Azure.


En nuestro caso, tanto en el campo PUBLIC PORT como en PRIVATE PORT deberemos ingresar el puerto correspondiente. 

Nota importante: es aconsejable no utilizar el puerto default (1433). Sin embargo, haremos uso del mismo sólo por motivos educativos. Entonces ingresamos un nombre para el endpoint; seteamos el protocolo TCP y por último completamos los números de puertos:


Con esto, damos por finalizada la creación del endpoint.

2. Azure: habilitar el acceso a través del Firewall

A continuación, le indicaremos a Windows que queremos dejar pasar el tráfico proveniente de ese puerto que acabamos de habilitar. Para acceder a la configuración del firewall podemos presionar las teclas: Windows + R Y escribimos wf.msc. De esa manera se nos abre la siguiente ventana. Seleccionamos la sección Inbound Rules y luego hacemos clic en el botón New rule:


Hacemos clic en Siguiente o Next y seleccionamos la opción Port:


En la próxima ventana elegimos las opciones TCP y "Specific local ports:", en este último ingresamos el puerto 1433 según nuestro ejemplo.



Acto seguido, nos consulta qué tipo de acción queremos que ejecute el Firewall. Queremos que permita el tráfico así que seleccionamos: Allow the connection:


A continuación nos pregunta el alcance de la regla, dejamos las opciones tildadas por default y vamos a la próxima ventana.


Finalmente, le damos un nombre a nuestra regla y opcionalmente una descripción:


Cuando estamos listos, hacemos clic en Finish.

Verificamos que se haya creado la regla:


3. SQL Server Azure: verificar que el protocolo TCP está habilitado

Es bueno verificar que nuestro servidor SQL tenga habilitado el protocolo TCP, ¡nos ahorrá más de un dolor de cabeza! Para ello abrimos el SQL Server Configuration Manager y en la sección SQL Server Network Configuration verificamos que el protocolo TCP esté habilitado (enabled):


4. SQL Server Azure: configurar usuario

Ahora, debemos configurar un acceso en el propio motor de base de datos. Dependiendo de nuestra base y configuración, podríamos llegar a tener ya creado un usuario para "Acceso remoto":


Si ese es el caso, podríamos reutilizarlo. Sino debemos crear uno nuevo y asegurarnos de que tenga acceso a la base de datos a la cual nos queremos conectar.

5. Visual Studio local: Conectar remotamente a SQL Azure

Por último, vamos a revisar si finalmente todo nuestro esfuerzo fue suficiente para establecer la conexión. Para ello, abrimos el Visual Studio y seguimos los pasos necesarios para crear una solución de tipo SQL Server Project tal como está explicado en este artículo: Cómo serializar una base SQL con Visual Studio  

En esta ocasión, vamos a explicar cómo agregar un proyecto a una solución ya existente. Una vez abierta nuestra solución, hacemos clic derecho sobre la misma y seleccionamos Add -> New Project...:


Definimos el nombre del nuevo proyecto:


Verificamos que se haya agregado correctamente a la solución:


Lo próximo que vamos a hacer, es configurar el proyecto para que sea posible la conexión a Azure. Hacemos clic derecho sobre el mismo y abrimos las propiedades:


En el campo Target platform: seleccionamos Micosoft SQL Azure Database V12 (dependiendo del tipo de versión de base de datos que tengamos en Azure).


El próximo paso es "importar" la base de datos a nuestro proyecto. Para dar curso a ello, iremos a la solución y haremos clic derecho, luego seleccionaremos Import -> Database...:


En la ventana que aparece, hacemos clic en New connection...:


Como también vemos en la imagen de arriba, configuramos los siguientes campos:
  • Server name: ingresamos el nombre de nuestra máquina virtual, es decir, el mismo que usamos para acceder remotamente.
  • Log on to the server: seleccionamos la opción Use SQL Server Authentication y completamos tanto el User name: (ej.: RemoteUser) y la Password.
  • Finalmente, en Select or enter a database name: seleccionamos el nombre de nuestra base de datos.
Para terminar hacemos clic en Ok y empezará la importación:


De esa manera ya tenemos toda la base de datos de SQL Azure serializada en nuestro proyecto de Visual Studio:


Damos entonces por cumplido nuestro objetivo de poder comunicarnos desde nuestro Visual Studio local a nuestra base SQL Azure. Esto nos habilita a obtener muchos beneficios como: realizar el versionado de la base de datos, facilitar el trabajo de equipos de varios miembros, impactar las modificaciones desde un acceso remoto, entre otros.

Autor:


Julián Haeberli
Baufest Technical Leader

miércoles, 10 de agosto de 2016

¿Cómo serializar una base SQL Server con Visual Studio?


Este artículo indica cómo podemos serializar una base de datos de SQL Server con Visual Studio y sus ventajas.

Serializar una base SQL en Visual Studio significa que tomaremos la estructura de una base previamente creada y la convertiremos en instrucciones SQL. ¿Y qué significa esto? Bueno, por ejemplo, si tenemos una tabla de artículos con dos campos: 


Al serializarla estaremos guardando una instrucción similar a esta:



¿Y para qué nos sirve hacer esto? Para responder esta pregunta pasaremos a la siguiente sección.

Beneficios

  • A diferencia de cuando editamos características en el SQL Server Management Studio, si en el proyecto de Visual Studio realizamos alguna modificación no deseada, podemos hacer rollback, siempre y cuando no se trate de datos en las tablas.
  • Las modificaciones pueden ser comiteadas directamente en un repositorio de fuentes como el Team Foundation Server (TFS).
  • Nos brinda la posibilidad de aplicar los cambios (deploy) en distintos ambientes con sólo cambiar la conexión.
  • Existe la posibilidad de crear scripts para insertar datos de pruebas o de tablas maestras luego de cada deploy, facilitando el testing de aplicaciones.
  • Se facilita el trabajo en equipo cuando el grupo de desarrollo es de varios miembros.
Desventajas

  • No versiona datos internos de las tablas, para ello hay sólo tres opciones:


  1. Hacer backups. Contra: pueden tener un tamaño de varios gigabytes.
  2. Crear scripts automáticamente que ingresen los datos a las tablas (insert into). Contra: la posterior ejecución de esos scripts demora horas.
  3. Crear un método complejo en el cual la información de cada registro de cada tabla no es borrada sino que tiene un estado, e incorporar fecha y hora. Contra:  el tamaño de las tablas se incrementa rápidamente, repercutiendo en la performance. Generalmente no se justifica el costo-beneficio de su implementación.

Manos a la obra

Bien, ahora que entendemos las opciones que nos brinda esta herramienta de Visual Studio, entonces pasaremos a comentar cómo es que se organiza.

Requisitos

Para empezar, debemos contar con las herramientas necesarias:

  • Visual Studio: desde la versión 2010 en adelante.
  • Acceso a un servidor SQL Server 2005 en adelante.

Creando el proyecto

Como siempre, en Visual Studio lo primero que haremos será crear una solución. En este caso, la que nos interesa es la de tipo "SQL Server Database Project". La crearemos de la siguiente forma:





El resultado es un proyecto nuevo y, obviamente, vacío:



Importando la base de datos

El próximo paso, es agregar la base de datos de SQL Server a nuestro nuevo proyecto. Para iniciar la importación hacemos clic derecho sobre el proyecto y seleccionamos la opción Import - Database:



Lo siguiente, es establecer una conexión desde Visual Studio al servidor SQL. P para ello, haremos clic en el botón New Connection...


Agregamos el nombre del servidor SQL en Server name luego desplegamos el combo Select or enter a database name: y seleccionamos la base de datos que vamos a serializar, para este ejemplo es la base de datos de nombre "Prueba":



Adicionalmente, podemos hacer clic en el botón Test Connection, pero si en el combo anteriormente ya nos muestra los nombres de las bases, podemos estar seguros de que la conexión funcionó perfectamente. 
Debemos mencionar que en este caso nuestra base de datos está configurada para aceptar el logueo de usuarios del mismo dominio de nuestra empresa: Active Directory. Si ese no fuese el caso, podemos agregar un usuario dentro del servidor SQL y establecemos la conexión utilizando ese usuario seleccionando la opción Use SQL Server Authentication. Una vez que aceptamos esta ventana, regresamos al formulario de importación y aprovechamos entonces para verificar que haya quedado seleccionada la base de datos que queremos serializar:


Iniciamos el proceso de importación haciendo clic en el botón Start, este es el resultado:



Vemos que se agregó un archivo al proyecto:



Este archivo es el resultado de serializar la tabla Artículos que habíamos creado. Recordemos que este es un ejemplo sencillo para facilitar el aprendizaje. Una base de datos productiva está compuesta de tablas, procedimientos almacenados, funciones, varios usuarios, y otros componentes;odos ellos pueden ser serializados en nuestro proyecto. 
Al abrir el archivo Articulos.sql vemos cómo Visual Studio lee el código contenido en él y dibuja una tabla, además de mostrar el código fuente:



De esta manera, vemos lo fácil que es serializar una base de datos. Simplemente hay que crear un proyecto, establecer la conexión e importar la base. El resto es automático.

Autor:


Julián Haeberli 
Baufest Technical Leader