Desmitificando Branches por Victor Passador

8. junio 2010

En el tiempo que llevamos trabajando en consultoría relacionada con TFS, y en particular con lo concerniente al Source Control, nos hemos encontrado con dos tipos de casos:

  • Empresas que no aprovechan los beneficios aportados por el branching.
  • Empresas que hacen abuso del branching, que también pierden esos mismos beneficios y terminan siendo devorados por el monstruo.

 

Los primeros no quieren ni hacer mención al branching por simple temor a lo desconocido, pero en cuanto vencen ese primer miedo y obtienen los primeros buenos resultados, se convierten automáticamente en los de la segunda clase, casi sin término medio.

Los segundos vuelven a convertirse en los primeros por abandono.

Con este post me propongo  hacer una introducción a las políticas de branches, para que ambos grupos puedan lograr el equilibrio.

Branching Guidance

En gran parte de los casos con los que me he cruzado, el caos viene de la mano de la falta de políticas de branches. Casi como la planificación previa de la arquitectura de cualquier aplicación, los branches necesitan ser diagramados y consensuados de antemano.

Desde hace varios años ya, está publicada en Codeplex lo que se conoce como “Branching Guidance” sobre la cual estoy basando este post. Hoy la guía se encuentra en su versión 2.0 a raíz del feedback recibido desde la comunidad y recientemente fue publicado el Release 2010, obviamente apuntando al lanzamiento de la nueva versión de la plataforma.

En esa guía hay una frase a modo de advertencia que me gustaría transcribir:

Cada branch que se crea tiene un costo, por lo tanto asegúrese de obtener algún valor de él.

Creo que esta frase resume perfectamente el concepto de equilibrio al que hacía referencia  anteriormente, y al punto al que deberían llegar las empresas que decidan apostar por una política de branches.

Apostando a una política de branches

El uso de branching requiere ordenamiento, y por tal motivo voy a enumerar algunos principios que se deberán tener en cuenta antes de meter mano:

  • El encargado de ejecutar y mantener la política de branches que se defina, deberá tener un nivel medio-avanzado en el manejo de TFS. (“Cada branch tiene un costo …”).
  • La política que se defina dependerá fuertemente de los tipos de Release (release de nueva versión, de service pack, de hot fix, etc.) requeridos por el proyecto en cuestión, de lo que se desprende:
    • Se pueden definir diferentes tipos de políticas para diferentes tipos de proyecto.
    • A menor cantidad de tipos de release, un plan de branching más simple.

 

Los planes de branching sugeridos en la guía tienen una característica “aditiva” lo que permite elegir en primera instancia un plan simple, y en caso de que aparezcan nuevos tipos de release (conocidos como release vehicles, ver Glosario) ir “complicando” el plan agregando nuevos branches.

Un plan equilibrado – El “Standard Branch Plan”

Imaginemos un escenario con las siguientes características:

  • Se desarrolla un producto del cual el cliente siempre tiene la última versión.
  • Se desarrollan permanentemente nuevas versiones con nuevos features (un release vehicle por aquí).
  • Se entregan además actualizaciones (services packs, bug fixes, otro release vehicle por aca).
  • Cada actualización liberada sobre una determinada versión contiene todas las actualizaciones anteriores.
  • Los services packs se desarrollan paralelamente a los features de la nueva versión.

 

Dado este escenario, un plan de branches como el que muestro a continuación permitiría soportar las necesidades del proyecto a la vez que mantendría una cantidad de branches controlada, fuera de una situación de caos.

image

Qué propone este plan:

  • Branch Development:
    • Sobre él se desarrollan los features de la próxima versión.
    • Existe un flujo continuo desde y hacia el branch Main (merges).
    • Merge hacia Main (RI) ante cada objetivo cumplido, por ejemplo el fin de una iteración.
    • Merge desde Main (FI) cada vez que Main genera un build exitoso.
  • Branch Service Pack:
    • Se crea en el mismo instante que Release, determinando en ese momento la jerarquía Main –> Service Pack –> Release.
    • Los cambios “de servicio” se hacen sobre esta rama y luego se hace merge (RI) sólo hacia Main.
  • Branch Release:
    • Es hijo de Service Pack.
    • La entrega al cliente se hace desde este branch, y una vez que se libera, el branch se marca como read-only.
    • Bug fixes graves, que se hagan sobre el branch Release, deben hacer merge hacia Main pero pasando por el branch Service Pack (Release –> Service Pack –> Main)
    • Una vez que se creó este branch, los cambios que no fueron aprobados para el Release en curso sólo deberían hacerse en Main.

 

Herramientas de TFS

Con el lanzamiento de TFS 2010, se agregaron nuevas ventajas que facilitarán la vida del desarrollador que se encuentre con la difícil tarea de hacer los merges al momento de incorporar cambios a los diferentes branches, entre los que tenemos:

Visualización gráfica de la jerarquía de branches …

image

y visualización gráfica de los merges a los diferentes branches (incluye línea de tiempo …)

image

Con esta última mejora, podremos saber si un determinado cambio fue incorporado a un branch que lo requiera (si no se hubiera hecho el merge, el branch se vería en color rojo), y además, podemos saber en qué fecha y con qué changeset fue realizado.

Conclusión

Lograr equilibrios no es sencillo, pero los beneficios pueden ser muchos.

Invertir tiempo en la planificación y el mantenimiento de una política de branches que cubra nuestras necesidades pero que a la vez no se descontrole puede no ser fácil, pero seguramente permitirá reducir llamados de nuestros clientes enviando saludos a nuestras hermanas, madres y abuelas porque la entrega de la última versión, con aquellos fantásticos nuevos features, revivió bugs que habían sido ya solucionados.

Glosario

Development Branch con los cambios de la próxima versión
Main Es la conjunción de los branches Development y Release. Representa un “foto” estabilizada del producto que podría ser compartida, por ejemplo, con el equipo de QA
Service Pack Una colección de bug fixes que apuntan a la última versión liberada
Release Un branch sobre el que se hacen cambios de último momento o bug fixes de alta prioridad
Forward Integrate (FI) Merge desde branches padres a hijos
Reverse Integrate (RI) Merge desde branches hijos a padres
Release Vehicle Es la forma en que el producto llega al cliente

ALM, Gestión de Proyectos, TFS

Manage IT 2010 - Gestión de Proyectos y Arquitectura de Software por Daniel Laco

26. abril 2010

Se viene el evento nuevamente !!!

 

Este año estaremos repitiendo el evento sobre Gestión de Proyectos y Arquitectura de Software.

VEMN SA conjuntamente con el MUG, Lagash SA y el apoyo de la Universidad Argentina de la Empresa (UADE) realizaremos el evento el día 8 de Junio a las 9.00 hs. en la sala Magna de la UADE.

Temario

8:30 - 9:30 Acreditación
9:30 – 10:00 Presentación del Evento y KeyNote
10:00 – 11:15 Value Express. Optimizando los resultados de sus inversiones realizadas.
(Susana Silberberg)
11:15 - 11:45 Break
11:45 – 13:00 Desarrollo de aplicaciones de misión crítica.
(Diego Gonzalez y Rodolfo Finochietti)
13:00 – 14:15 Almuerzo Libre
14:15 – 15:30 Estimación de Proyectos de Software. La cara oculta de las diferencias.
(Daniel Laco y Patricia Scalzone)
15:30 – 16:00 Break
16:00 – 17:15 ¿Sueñan los Gerentes de IT con programadores eléctricos?
(Luis Ávalo)
17:15 – 17:30 Cierre y Sorteos
Es un evento de interés para profesionales de TI, Gerentes de Sistemas, Líderes de Proyectos, Arquitectos, Analistas y todo aquel interesado en el mundo TI.


El evento es gratuito. Vacantes limitadas, con inscripción previa.

Para mas información en www.manageit.com.ar.


ALM, Eventos, Gestión de Proyectos, Metodologías y Procesos, Tecnología , , , , ,

Enviando JSON a una acción en ASP.NET MVC por Fernando Abuin

22. abril 2010

 

Descargar Código Fuente

El otro día estaba intentando enviar datos a una acción utilizando el AJAX de jQuery. En la mayoría de los casos, podrán utilizar este método y enviar datos a una acción sin problemas, ya que el default binder de MVC se encarga de interpretar los datos.

Mi problema surgió cuando intenté enviar datos más complejos. En el controlador tenía el siguiente método:

   1:          [AcceptVerbs(HttpVerbs.Post)]
   2:          public virtual JsonResult Actualizar(Producto producto)
   3:          {
   4:              //HACER ALGO 
   5:          }

Este método sólo acepta un POST, y tiene un argumento de tipo Producto. Veamos cómo está compuesta esta clase:

   1:      public class Producto
   2:      {
   3:          public int Id { get; set; }
   4:          public string Nombre { get; set; }
   5:          public IEnumerable<Promocion> Promociones { get; set; }
   6:   
   7:          public class Promocion
   8:          {
   9:              public string Id { get; set; }
  10:              public double Descuento { get; set; }
  11:              public DateTime FechaDesde { get; set; }
  12:              public DateTime FechaHasta { get; set; }
  13:          }
  14:      }

 

Para poder enviar esto utilizando jQuery y AJAX, lo más sencillo sería hacer:

   1:      var data = {
   2:          "Id": 1,
   3:          "Nombre": "Cualquier Nombre",
   4:          "Promociones": [
   5:         {
   6:             "Id": 1,
   7:             "Descuento": 0.15,
   8:             "FechaDesde": new Date(año, mes, día),
   9:             "FechaHasta": new Date(año, mes, día)
  10:         },
  11:         {
  12:             "Id": 2,
  13:             "Descuento": 0.05,
  14:             "FechaDesde": new Date(año, mes, día),
  15:             "FechaHasta": new Date(año, mes, día)
  16:         }
  17:       ]
  18:      };
  19:   
  20:      $.ajax({
  21:          type: "POST",
  22:          dataType: "json", // Tipo de dato que devuelve el server
  23:          url: 'Controller/Action',
  24:          data: data, // Datos a enviar
  25:          success: function(serverResponse) {
  26:              // Realizar algo cuando la llamada es exitosa
  27:          },
  28:          error: function() {
  29:              // Realizar algo cuando la llamada falla
  30:          }
  31:      });
 

Lo que estoy haciendo es crear un objeto con los miembro Id, Nombre y Promociones y asignándolo a la variable data.

Sin embargo, el miembro Promociones es un objeto de tipo Array. Por default, la función $.ajax() intentará convertir cualquier dato a un string. Como Promociones es un array, al intentar convertirlo a un string, terminará enviando al servidor lo siguiente:

IDDivision=6&IDBonificacion=LB6&Tipo=A&Vigencias=[object+Object]&Vigencias=[object+Object]

Es decir, jQuery serializa los valores de un mismo array con el mismo Key. Por ejemplo, {foo:["bar1", "bar2"]} se convierte en '&foo=bar1&foo=bar2'.

Sin embargo, como el valor de cada elemento de Promociones es otro objeto, lo que termina enviando es el .toString() del objeto, el cual es "[object Object]" justamente. El Default Model Binder de ASP.NET MVC, intentará hacer el bind al objeto Producto, pero debido a que jQuery serializo incorrectamente el objeto, el miembro Promociones terminará siendo null, en lugar de los datos que estábamos intentando enviar realmente.

Para resolver este problema, podemos convertir los objetos javascript a JSON. Para hacer esto, utilicé JSON for jQuery (link), pero se puede utilizar cualquier cosa que tome un objeto javascript y lo transforme a JSON. Al enviar los datos al server, debemos asegurarnos que el content type sea del tipo application/json, que es lo que estoy haciendo en la línea 5 del siguiente código:

 

   1:      var jsonString = $.toJSON(data);
   2:      $.ajax({
   3:          type: "POST",
   4:          dataType: "json", // Tipo de dato que devuelve el server
   5:          contentType: 'application/json', // Tipo de datos que envío
   6:          url: 'Controller/Action',
   7:          data: jsonString, // Datos a enviar
   8:          success: function(serverResponse) {
   9:              // Realizar algo cuando la llamada es exitosa
  10:          },
  11:          error: function() {
  12:              // Realizar algo cuando la llamada falla
  13:          }
  14:      });

Fíjense que antes de hacer la llamada a ajax(), estoy transformando la variable data a JSON, y pasando su resultado a la función $.ajax(), en lugar del objeto. La variable jsonString entonces quedará en:

'{"Id": 1, "Nombre": "Cualquier Nombre", "Promociones": [{ "Id": 1, "Descuento": 0.15, "FechaDesde": "2010-01-01T03:00:00.000Z", "FechaHasta": "2010-05-31T03:00:00.000Z" }, { "Id": 2, "Descuento": 0.05, "FechaDesde": "2010-06-02T03:00:00.000Z", "FechaHasta": "2010-08-01T03:00:00.000Z" } ] }'

Si prestan atención, podrán darse cuenta que el JSON string es exactamente igual que la declaración de la variable data, definida más arriba. La única diferencia es que jsonString es literalmente un string, y data es un objeto javascript.

Ahora, lo único que queda resolver es el Model Binding del lado del servidor. Lamentablemente, ASP.NET MVC 2 no interpreta JSON correctamente, por lo tanto vamos a tener que hacer algo para hacerlo funcionar.

El enfoque más común sería hacer un Custom Model Binder. Sin embargo, esto implica que en cada acción que recibe JSON, debemos indicar explícitamente a MVC que utilice nuestro Model Binder. Si se trata de una sola acción, no habría ningún problema, pero si hay muchas acciones que utilizan el Model Binder, y todas reciben distintos tipos de datos, se va a volver muy tediosa la implementación.

Por suerte, en MVC 2, tenemos algo llamado Value Providers. Mientras que los Model Binders son utilizados para bindear datos que recibe el servidor, Value Providers proveen una abstracción para los datos en sí.

Para resolver mi problema, creé un Custom Value Provider que recibe datos JSON y lo serializa a un diccionario, en lugar de al objeto. Luego, éste diccionario es pasado al Default Model Binder de MVC, el cual realiza el bind al objeto final, e incluso realiza cualquier validación que ustedes hayan indicado.

El Custom Value Provider es el siguiente:

   1:  public class JsonValueProviderFactory : ValueProviderFactory
   2:  {
   3:      public override IValueProvider GetValueProvider
   4:                                           (ControllerContext controllerContext)
   5:      {
   6:          object jsonData = GetDeserializedJson(controllerContext);
   7:   
   8:          if (jsonData == null)
   9:              return null;
  10:   
  11:          var dictionary = new Dictionary<string, object>
  12:                                             (StringComparer.OrdinalIgnoreCase);
  13:   
  14:          FlattenToDictionary(dictionary, string.Empty, jsonData);
  15:   
  16:          return new DictionaryValueProvider<object>
  17:                                       (dictionary, CultureInfo.CurrentCulture);
  18:      }
  19:   
  20:      private static object GetDeserializedJson
  21:                                           (ControllerContext controllerContext)
  22:      {
  23:          if (!controllerContext.HttpContext.Request.ContentType
  24:            .StartsWith("application/json", StringComparison.OrdinalIgnoreCase))
  25:              return null;
  26:   
  27:          string bodyText = new StreamReader
  28:                (controllerContext.HttpContext.Request.InputStream).ReadToEnd();
  29:   
  30:          if (string.IsNullOrEmpty(bodyText))
  31:              return null;
  32:   
  33:          var serializer = new JavaScriptSerializer();
  34:   
  35:          return serializer.DeserializeObject(bodyText); 
  36:      }
  37:   
  38:      private static void FlattenToDictionary(
  39:            IDictionary<string, object> dictionary, string prefix, object value)
  40:      {
  41:          var dictionaryValue = value as IDictionary<string, object>;
  42:   
  43:          if (dictionaryValue != null)
  44:          {
  45:              foreach (KeyValuePair<string, object> entry in dictionaryValue)
  46:              {
  47:                  string propertyKey;
  48:   
  49:                  if (!string.IsNullOrEmpty(prefix))
  50:                      propertyKey = prefix + "." + entry.Key;
  51:                  else
  52:                      propertyKey = entry.Key;
  53:   
  54:                  FlattenToDictionary(dictionary, propertyKey, entry.Value);
  55:              }
  56:          }
  57:          else
  58:          {
  59:              var listValue = value as IList;
  60:              if (listValue != null)
  61:              {
  62:                  for (int i = 0; i < listValue.Count; i++)
  63:                      FlattenToDictionary(dictionary,
  64:                                          prefix + "[" + i + "]", listValue[i]);
  65:              }
  66:              else
  67:                  dictionary[prefix] = value;
  68:          }
  69:      }
  70:  }

Y luego, debemos agregar la siguiente línea en el Global.ajax de nuestra aplicación:

   1:  protected void Application_Start()
   2:  {
   3:          RegisterRoutes(RouteTable.Routes);
   4:          ValueProviderFactories.Factories.Add(new JsonValueProviderFactory());
   5:  }

Listo! Ahora al enviar JSON al servidor, nuestro Value Provider interceptará el request, y serializará los datos de tipo JSON a un diccionario que pueda ser interpretado por el Default Model Binder. Lo único que debemos recordar hacer es setear el ContentType a 'application/json', y éstos requests serán procesados por nuestro Value Provider.

Ahora, veamos un poco qué está haciendo el Value Provider.
Al único método que tenemos que hacerle override de la clase ValueProviderFactory es a GetValueProvider(). Lo que hace es deserializar JSON y transformarlo en un objeto .NET, luego lo serializa al diccionario y devuelve un DictionaryValueProvider, el cual es utilizado más tarde por el default model binder.

El método GetDeserializedJson() hace exactamente lo que dice, deserializa JSON. Hay que tener cuidado de pasarle un string que contenga JSON, porque puede arrojar una excepción si se pasa JSON invalido. Probablemente sería conveniente encerrar a la llamada DeserializeObject en un try/catch, y devolver null cuando falle.

Finalmente, el método FlattenToDictionary() es un método recursivo que recorre el objeto deserializado, que para este ejemplo es el siguiente:

clip_image002

Como verán, el objeto deserializado es un Dictionary<string, object>. Para Id y Nombre, el tipo de dato de Value es int y string respectivamente. Para Promociones, en cambio, es un Array de object, y cada elemento de ese Array es un Dictionary<string,object>. Lo que hace FlattenToDictionary() es recorrer todos estos elementos para 'aplanarlo' (flatten) a un diccionario. El método nos devuelve esto:

clip_image004

Si leyeron el post de Andres Stang probablemente esto les resulte familiar. Lo que hace el método es recorrer el objeto, y construir el Key de cada uno de los valores que contiene para poder insertarlo en un diccionario, donde todos los valores de cada elemento sea un tipo de dato primitivo. Este diccionario luego es interpretado por el default model binder. Es decir, lo que estamos haciendo es transformar JSON a un formato que pueda ser interpretado por el default model binder.

Les dejo el código fuente con una aplicación de ejemplo para que prueben:

JsonToMVCAction.rar (153,28 kb)

.NET, ASP.NET, Desarrollo Web, JQuery , , ,

Lanzamiento Virtual “La eficiencia en tus manos” por Daniel Laco

16. abril 2010

Hola a todos, quiero recordarles que este 21 de Abril será el evento virtual de lanzamiento de 11 importantes productos y donde muchos MVPs estaran como speakers y como expertos para resolver tus dudas.

clip_image003_010b7c0b-5450-4bae-8599-79e3ef3ca26b

 clip_image001_0d130959-9982-4736-8319-5fff7ce34ca4

 

 

clip_image002_f403aaf7-c2c3-4e8d-beb7-f7bb8c027891

Regístrate ya!

.NET, ASP.NET, Entity Framework, General, Sharepoint, Visual Studio

Cuál es la mejor forma de realizar procesos batch con Entity Framework? por Daniel Laco

16. abril 2010

Es muy común que en las aplicaciones sea necesario realizar procesos de actualizaciones masivas. Siempre está la tentación de usar EF para hacer estos procesos, ya que es muy fácil buscar y actualizar registros. Pero en el caso de EF el costo que se paga por toda la infraestructura que tiene es muy alto.

En el caso de procesos masivos, si hay que actualizar o borrar un registro, primero hay que traerlo (esto implica que EF mantenga el tracking con el ObjectStateManager) posteriormente hacer la actualización o borrado y por último realizar la actualización con el ObjectContext.

Resumiento, para realizar procesos batch lo mejor es NO USAR Entity Framework !!

Pero que opciones tengo entonces?

Voy a mostrar 2 alternativas de las muchas que hay, simulando que hay que leer un archivo .TXT de longitud fija  y posteriormente hay que realizar una actualización de miles de registros en una tabla de la base de datos.

El escenario es que recibo un archivo con códigos de productos de la empresa y códigos de productos de proveedores externos. El proceso que hay que realizar es: leer el archivo y actualizar los códigos de de los proveedores externos en cada registro de los productos de la empresa.

Para esto usaremos como ayuda la excelente libreria FileHelpers realizada por Marcos Meli

El formato en que viene el archivo es el siguiente:

 

/// <summary>
/// Archivo de Unión de Códigos de Productos de la Empresa y Proveedores
/// </summary>
 
[FixedLengthRecord(FixedMode.AllowLessChars)]
public class UnionProductos
{
    [FieldFixedLength(7)]
    public int EmpresaCodigo;
 
    [FieldFixedLength(7)]
    public string Proveedor1Codigo;
 
    [FieldFixedLength(7)]
    public int Proveedor2Codigo;
 
}

 

El proceso de lectura con FileHelpers:

FileHelperEngine engine = new FileHelperEngine(typeof(UnionProductos));
UnionProductos[] UnionLeido = engine.ReadFile(nombreArchivo) as UnionProductos[];
 
 

Opción 1

Recorrer el array de Productos y ejecutar un Store Procedure con la actualización correspondiente:

 

string stringDeConexion = "XXXXXXXXXXXXXXXX";
using (SqlConnection conn = new SqlConnection(stringDeConexion))
{
    conn.Open();
    SqlCommand cmd = new SqlCommand("nombreStore", conn);
    cmd.Parameters.Add("@empresaCodigo", SqlDbType.Int);
    cmd.Parameters.Add("@proveedor1Codigo", SqlDbType.VarChar);
    cmd.Parameters.Add("@proveedor2Codigo", SqlDbType.Int);
 
 
    foreach (UnionProductos producto in UnionLeido)
    {
        cmd.Parameters[0] = producto.EmpresaCodigo;
        cmd.Parameters[1] = producto.Proveedor1Codigo;
        cmd.Parameters[2] = producto.Proveedor2Codigo;
 
        cmd.EndExecuteNonQuery();
 
    }
}

 

Por supuesto el Store hace algo asi como:

UPDATE Productos 
SET Proveedor1Codigo = @proveedor1Codigo, 
    Proveedor2Codigo = @proveedor2Codigo
WHERE Productos.Codigo = @empresaCodigo

 

Opción 2

Esta es la mas performante de las 3 opciones. El único problema es que solo es posible en SQL Server 2008.

Está implementada utilizando una Tabla como Parámetro y realizando toda la actualización mediante una sentencia SQL.

Veamos como hacelo:

Se crea un tipo de dato Table en SQLServer

CREATE TYPE UnionProductosTbl AS TABLE 
(
    EmpresaCodigo int,
    Proveedor1Codigo varchar(7),
    Proveedor2Codigo int
)

 

Se crea el Procedimiento Almacenado usando ese tipo como parámetro:

CREATE PROCEDURE ActualizarCodigosProveedores
    @unionProductosTbl dbo.UnionProductosTbl READONLY
AS
BEGIN
 
    UPDATE Productos p
    SET p.Proveedor1Codigo = tbl.Proveedor1Codigo,
    p.Proveedor2Codigo = tbl.Proveedor2Codigo
    FROM Productos
    INNER JOIN @unionProductosTbl tbl ON p.Codigo = tbl.empresaCodigo
    
END

 

Y el proceso en el código:

//Lectura del Archivo
               FileHelperEngine engine = new FileHelperEngine(typeof(UnionProductos));
               //Devuelve como DataTable
               DataTable unionLeidoDT = engine.ReadFileAsDT(nombreArchivo);
 
               //El proceso de actualización
               string stringDeConexion = "XXXXXXXXXXXXXXXX";
               using (SqlConnection conn = new SqlConnection(stringDeConexion))
               {
                   conn.Open();
                   SqlCommand cmd = new SqlCommand("nombreStore", conn);
                   //Se define un parámetro de tipo Structured para que reciba un DataTable
                   SqlParameter par = cmd.Parameters.Add("@unionProductosTbl", 
                       SqlDbType.Structured);
                   par.Value = unionLeidoDT;
                   cmd.EndExecuteNonQuery();
               }
               
 

Realizando el proceso con 17.000 registros los resultados fueron los siguientes (los tiempos son orientativos):

Opción Tiempo

Utilizando EF

8 minutos

Utilizando ADO.NET nativo procesando registro a registro con un Store Procedure

4 minutos

Utilizando un Store Procedure en SQL 2008 con una tabla como parámetro

4 segundos !!

 

Para finalizar, la opción de realizar el proceso batch usando una tabla como parámetro de un Store es la mejor opción si la prioridad es la performance de la solución.

ADO.NET, Entity Framework, SQL Server ,

Versiones de VS 2010 por Daniel Laco

15. abril 2010

Siempre es motivo de preguntas el tema de que trae cada versión de Visual Studio y cuanto cuesta cada una de ellas. Aqui les dejo un link donde ver una matriz con las comparaciones de cada versión de Visual Studio 2010.

Visual Studio

Formulario Cabecera-Detalle en Asp.Net MVC con el default ModelBinder por Andres Stang

30. marzo 2010

 

Descargar Codigo Fuente

Tal vez les suceda que alguna vez en su feliz programación de Asp.Net MVC quieren generar un formulario de entrada de datos que permita, sin los molestos tiempos de carga de postback, agregar N cantidad de elementos.

Es decir, generar un modelo de Cabecera-Detalle en el cliente, y luego poder leerlo del lado servidor utilizando solo MVC y Javascript. No, me refiero a SOLO MVC, es decir sin un ModelBinder personalizado, que sería la opción que primero nos viene a la mente gracias a la extensibilidad propuesta por el framework.

Podemos imaginarnos el siguiente ejemplo de modelo:

   1: public class Materia
   2: {
   3:     public int Codigo { get; set; }
   4:     
   5:     public string Nombre { get; set; }
   6:  
   7:     public List<Alumno> AlumnosInscriptos { get; set; }
   8: }

Supongamos que queremos permitir al usuario generar una nueva materia y asignarle alumnos a la misma desde una lista de selección. Para simplificar el alumno va a estar definido por:

   1: public class Alumno
   2: {
   3:     public int Matricula { get; set; }
   4:  
   5:     public string Nombre { get; set; }
   6: }

 

Entonces realizamos el siguiente formulario web:

 

En el mismo vamos a poder cargar las propiedades de la materia y mediante javascript permitiremos que se agreguen los alumnos al seleccionarlos del combo al presionar “Agregar”.

Pero… como hacemos luego para leer las propiedades de la materia y los N alumnos seleccionados del lado del servidor?

Muy fácil, utilizando el ModelBinder por defecto de MVC. Es decir, el framework ya viene preparado para este escenario, solo que (a mi apreciación) está poco documentado.

Es decir, en nuestro método de controlador solo tendremos que colocar la siguiente definición:

   1: [AcceptVerbs(HttpVerbs.Post)]
   2: public ActionResult Index(Materia nuevaMateria)
   3: {
   4:     // HACER ALGO CON LA NUEVA MATERIA
   5:  
   6:     ViewData["CantidadAlumnos"] = nuevaMateria.AlumnosInscriptos.Count;
   7:  
   8:     return View("Alumnos");
   9: }

Y automáticamente podemos leer la instancia de la clase Materia con sus alumnos relacionados.

Donde está el secreto???

Lo importante es que al generar las filas dinámicamente de la tabla de alumnos también generemos los inputs para los valores de los alumnos que vayamos agregando. Por ejemplo, al agregar la fila nueva también insertaremos dos inputs ocultos de html con los valores que requiere la clase Alumno, es decir Matricula y Nombre:

   1: <input type="hidden" value="22" name="AlumnosInscriptos[1].Matricula" 
   2:     id="AlumnosInscriptos[1].Matricula" />
   3: <input type="hidden" value="Pedro" name="AlumnosInscriptos[1].Nombre" 
   4:     id="AlumnosInscriptos[1].Nombre" />

Podemos observar la particularidad del nombre y id del tag, es decir, debemos llamarlos de la siguiente manera:

<NombrePropiedadPadre>[indice].<NombrePropiedadHijo>

O para nuestro ejemplo:

AlumnosInscriptos[0].Nombre

De esta manera, el ModelBinder interpretara que se trata un elemento perteneciente a nuestra colección y nos facilitara el trabajo.

 

 

Pongo a disposición el código fuente perteneciente al ejemplo de este post:

ListBinder.zip (264,49 kb)

Happy Programming!

ASP.NET, Desarrollo Web , ,

Extensibilidad en el Entity Framework Designer en VS2010 por Daniel Laco

23. marzo 2010

 

Una de las cosas mas intersantes que tiene el diseñador del EF en Visual Studio 2010 es la posiblidad de extender las funcionalidades mediante el agregado de nuevas propiedades a una entidad, o la posibilidad de poder interceptar el momento de grabar un archivo edmx, u otras opciones mas.

Esto es muy útil para cuando hay equipos de desarrollo extendidos, o varios proveedores diferentes trabajando en una empresa  y se quiere mantener una uniformidad al momento de escribir código.

Asi que mediante un ejemplo sencillo explicaremos los pasos necesarios para poder implementar una propiedad en las entidades que nos permita definir si una entidad es auditada o no.

Mostraremos como agregar esa propiedad y como utilizarla posteriomente en nuestro código.

Aclaración: todo lo mostrado en este artículo, está realizado sobre la RC de VS2010.

Como paso siguiente, manos a la obra!!

El equipo de ADO.NET publicó en CodePlex el ADO.NET Entity Data Model Designer Extension Starter Kit que nos permite hacer mucho mas fácil la tarea, y ya tiene varias opciones configuradas por default.

Podemos por ejemplo: 

      • Que el ADO.NET Entity Data Model Wizard agregue anotaciones personalizadas en cada tipo de entidad. El fundamento del tema lo encontramos en un ar tículo del blog de ADO.NET referido a diseño en http://blogs.msdn.com/efdesign/archive/2008/08/12/structural-annotations-one-pager.aspx (en inglés)
      • Que el ADO.NET Entity Data Model Wizard agregue anotaciones personalizadas durante las actualizaciones en cada entidad que se agregue al modelo conceptual.
      • Que el ADO.NET Entity Data Model Wizard agregue anotaciones personalizadas cuando las entidades son seleccionadas en el Designer o en el Model Browser.
      • También se puede extender el modo en se que cargan y graban los archivos .admx.
      • O permitir que el Diseñador grabe o carge archivos en un formato personalizado.

 

Paso 1: Instalar la extensión que se baja desde CodePlex

ExtensionManager

Paso 2: Crear el proyecto.

CrearProyecto

Paso 3: Una vez que tenemos el proyecto creado, podemos hacer las modificaciones que nos interesan. En este caso vamos a crear una propiedad para cada Entidad que nos permita habilitar o deshabilitar la auditoría. Creamos entonces una clase AuditarProperty:

using System;
using System.Linq;
using System.Xml.Linq;
using System.ComponentModel;
using Microsoft.Data.Entity.Design.Extensibility;
 
namespace EFEjemploExtension
{
    /// <summary>
    /// </summary>
    class AuditarProperty
    {
        internal static readonly string _namespace = "http://schemas.vemn.com/EFExtensions";
        internal static XName _xnMyNamespace = XName.Get("AuditarProperty", _namespace);
        internal const string _category = "Extensiones";
 
        private XElement _parent;
        private PropertyExtensionContext _context;
 
        public AuditarProperty(XElement parent, PropertyExtensionContext context)
        {
            _context = context;
            _parent = parent;
        }
 
        // Esta propiedad This property is saved in the conceptual content of an .edmx document in the following format:
        // <EntityType>
        //  <!-- other entity properties -->
        //  <MyNewProperty xmlns="http://schemas.vemn.com/MyNewProperty">True</MyNewProperty>
        // </EntityType>
        [DisplayName("Auditar Entidad")]
        [Description("Configura si la entidad es Auditable")]
        [Category(AuditarProperty._category)]
        [DefaultValue(false)]
        public bool AuditarEntidad
        {
            get
            {
                bool propertyValue = false;
                if (_parent.HasElements)
                {
                    XElement lastChild = _parent.Elements().Where<XElement>(element => element != null && element.Name == AuditarProperty._xnMyNamespace).LastOrDefault();
                    if (lastChild != null)
                    {
 
                        bool boolValue = false;
                        if (Boolean.TryParse(lastChild.Value.Trim(), out boolValue))
                        {
                            propertyValue = boolValue;
                        }
                    }
                }
                return propertyValue;
            }
 
            set
            {
                bool propertyValue = value;
 
 
                using (EntityDesignerChangeScope scope = _context.CreateChangeScope("Set AuditarEntidad"))
                {
                    if (_parent.HasElements)
                    {
                        XElement lastChild = _parent.Elements().Where<XElement>(element => element != null && element.Name == AuditarProperty._xnMyNamespace).LastOrDefault();
                        if (lastChild != null)
                        {
 
                            lastChild.SetValue(propertyValue.ToString());
                        }
                        else
                        {
                            _parent.Elements().Last().AddAfterSelf(new XElement(_xnMyNamespace, propertyValue.ToString()));
                        }
                    }
                    else
                    {
                        _parent.Add(new XElement(_xnMyNamespace, propertyValue.ToString()));
                    }
  scope.Complete();
                }
            }
        }
    }
}

 

Paso 4: Creamos el Factory.

using System.Xml.Linq;
using System.ComponentModel.Composition;
using Microsoft.Data.Entity.Design.Extensibility;
 
namespace EFEjemploExtension
{
    [PartCreationPolicy(CreationPolicy.Shared)]
    [Export(typeof(IEntityDesignerExtendedProperty))]
    [EntityDesignerExtendedProperty(EntityDesignerSelection.ConceptualModelEntityType)]
    class AuditarPropertyFactory : IEntityDesignerExtendedProperty
    {
        /// <summary>
        /// </summary>
        /// <param name="element"></param>
        /// <param name="context"></param>
        /// <returns></returns>
        public object CreateProperty(XElement element, PropertyExtensionContext context)
        {
            return new AuditarProperty(element, context);
        }
    }
}

 

Paso 5: Una vez que hemos terminado, se compila y queda el arc hivo .vsix para ser in stalado en Visual Studio. En el Extension Manager veremos algo asi:

ExtensionInstalada>

Paso 6: Ya tenemos diponible la propiedad en el Diseñador de EF. Cuando agreguemos nuevas tablas o cuando se haga una actualización, las entidades tendrán ahora una nueva propiedad. Si seleccionamos una entidad veremos algo como:

AuditorPropiedad

 Paso 7: Por último, unos extension methods para poder consultar la Metadata del modelo que  nos permita obtener el valor de la propiedad:

 

public static class EFExtension
{
    /// <summary>
    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework
    /// </summary>
    /// <typeparam name="T">Entidad para obtener la propiedad</typeparam>
    /// <param name="workspace"></param>
    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>
    /// <returns></returns>
    public static bool GetExtentionPropertyAsBoolean<T>(this MetadataWorkspace workspace, string propertyName)
    {
        return (GetExtentionPropertyInternal<T>(workspace,propertyName).ToString().ToLower() == "true") ;   
    }
    /// <summary>
    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework
    /// </summary>
    /// <typeparam name="T">Entidad para obtener la propiedad</typeparam>
    /// <param name="workspace"></param>
    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>
    /// <returns></returns>
    public static string GetExtentionPropertyAsString<T>(this MetadataWorkspace workspace, string propertyName)
    {
        return GetExtentionPropertyInternal<T>(workspace, propertyName).ToString();
    }
 
    /// <summary>
    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework
    /// </summary>
    /// <typeparam name="T">Entidad para obtener la propiedad</typeparam>
    /// <param name="workspace"></param>
    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>
    /// <returns></returns>
    public static int  GetExtentionPropertyAsInt<T>(this MetadataWorkspace workspace, string propertyName)
    {
        return Convert.ToInt32(GetExtentionPropertyInternal<T>(workspace, propertyName));
    }
    /// <summary>
    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework
    /// </summary>
    /// <typeparam name="T">Entidad para obtener la propiedad</typeparam>
    /// <param name="workspace"></param>
    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>
    /// <returns></returns>
    public static object GetExtentionPropertyAsObject<T>(this MetadataWorkspace workspace, string propertyName)
    {
        return GetExtentionPropertyInternal<T>(workspace, propertyName);
    }
    /// <summary>
    /// Retorna el valor de una propiedad generada en la extensión del Diseñador del Entity Framework
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <param name="workspace"></param>
    /// <param name="propertyName">Ejemplo: http://schemas.vemn.com/EFExtensions:AuditarProperty</param>
    /// <returns></returns>
    private static object GetExtentionPropertyInternal<T>(MetadataWorkspace workspace, string propertyName)
    {
        StructuralType objectSpaceType;
        workspace.LoadFromAssembly(typeof(T).Assembly);
        if (!workspace.TryGetItem<StructuralType>(typeof(T).FullName, DataSpace.OSpace, out objectSpaceType))
        {
            throw new InvalidOperationException(String.Format(CultureInfo.CurrentCulture, "No se puede encontrar este tipo de datos en la Metadata", typeof(T)));
        }
        StructuralType edmType = workspace.GetEdmSpaceType(objectSpaceType);
 
        MetadataProperty mp = edmType.MetadataProperties.Where(x => x.Name == propertyName).Single();
        XElement xc = (XElement)mp.Value;
        return xc.Value;
    }
 
}

 

La forma de utilizar esta propiedad en nuestro codigo es:

NorthwindEntities ctx = new NorthwindEntities();
bool audita = ctx.MetadataWorkspace.GetExtentionPropertyAsBoolean<Customers>("http://schemas.vemn.com/EFExtensions:AuditarProperty");
//Hago algo con la auditoria

 

De esta forma, hemos visto como de manera relativamente sencilla se puede extender el Entity Designer y de que manera nos puede ayudar al momento de estandarizar configuraciones en las entidades.

Por supuesto que la cantidad de escenarios e ideas posibles con esta funcionalidad son muchas como pueden ser:

  • Revisión o Comenarios sobre los datos.
  • Seguridad en los Datos.
  • Agregado de Atributos del CLR
  • Validaciones de Anotaciones.
  • etc.
  • etc.

 

Aqui pueden bajar el código de ejemplo utilizado en el artículo.

 

 

 

 

ADO.NET, Entity Framework, ORM, Visual Studio , ,

Como depurar Store Procedures, Triggers y Functions de SQL Server desde Visual Studio 2008 por Emmanuel Carrara

22. marzo 2010

Una tarea imprescindible en el desarrollo y programación con SQL Server es la depuración (debugging) de Store Procedures, Triggers y Functions. El debugging nos permite ejecutar paso a paso código T-SQL, establecer breakpoints, examinar el contenido de las variables y modificarlos en tiempo de depuración, etc.

Anteriormente, los desarrolladores escribían y depuraban con el Analizador de consultas de SQL Server 2000 (Query Analyzer).

Luego, el SQL Server Management Studio 2005 que lo reemplazó no tenía ningún depurador, por lo cual para poder depurar código T-SQL se utilizaba el depurador que tiene el Visual Studio 2005.

A partir de la versión 2008 de SQL Server, las capacidades de debugging ya vienen incluidas en el Management Studio (solo funcionan con una conexión contra una instancia
de SQL Server 2008), sin embargo en ciertas ocasiones es más conveniente utilizar Visual Studio para el debugging de objetos de SQL.

Requerimientos

  • Versión Professional o Team Edition de Visual Studio.
  • Es importante destacar que al depurar se detendrán todos los threads de ejecución de SQL, de modo que no es recomendable depurar en un servidor que se encuentre en producción.
  • Activar el debugging de CLR en SQL: para esto se debe primero crear una conexión a la base de datos mediante la ventana "Server Explorer" (Menú "View"). Luego dar click derecho sobre la conexión y tildar la opción "Allow SQL/CLR Debugging"

 

EnableDebugging

Permisos

Para poder depurar código SQL desde Visual Studio 2008 existen dos cuentas de usuario para considerar:

  • La cuenta de la aplicación: es la cuenta de usuario sobre la cual se ejecuta Visual Studio. Esta cuenta es una cuenta de usuario de Windows, y debe ser miembro del grupo sysadmin en el SQL Server a ser depurado.
  • La cuenta de conexión: es la identidad usada para conectarse con SQL Server (Definida en el dialogo de conexión del "Server Explorer", o en el connection string). Esta cuenta puede ser una cuenta de usuario de Windows usando Windows Authentication (en este caso es la misma sobre la cual corre Visual Studio), o puede ser una cuenta de conexión SQL, en cuyo caso debe ser miembro del rol sysadmin para poder depurar.

 

Si no se cumplen los permisos requeridos para la Depuración de SQL Server, y se intenta depurar código de SQL Server, se obtiene el siguiente error:
User 'dbo' could not execute stored procedure 'master.dbo.sp_enable_sql_debug' on SQL Server VSQL01.

Pasos para la depuración

  • Ubicar el objeto a depurar en la ventana "Server Explorer".
  • Dar click derecho sobre el objeto que se desea depurar y seleccionar "Step into ..." ("Step into Store Procedure", "Step into Function", etc.)

 

StepInto 

  • Si requiere parámetros, aparecerá un cuadro de diálogo que permite asignar los valores para cada parámetro.

 

Parametros

  • En todo momento se puede visualizar o modificar el valor de variables locales, para lo cual podemos utilizar la ventana "Locals" de Visual Studio, disponible el menú "Debug" (solo cuando la depuración ha sido iniciada), o también mediante la ventana "Watch".

 

Debug

 

 

  • Para depurar un Trigger, se debe tener en cuenta que no se le puede invocar directamente, por lo cual, lo que se puede hacer es crear un Store Procedure cuyo código fuente invoque al Trigger, y utilizar Step Into (F11 - paso a paso por instrucciones) en vez de Step Over (F10 - paso a paso por el proceso actual) para la depuración, de manera de entrar en el código del Trigger en cuestión.

 

image

En el ejemplo se muestra un store procedure que ejecuta un UPDATE sobre la tabla que tiene el trigger a depurar. Al presionar F11 sobre la instrucción UPDATE se ingresa en modo depuración al código del trigger.

 

image

SQL Server , ,

Scripts seguros: Una historia de Transacciones, Stored Procedures y GOs por Leonardo Taibo

19. marzo 2010

Cuando trabajamos con bases de datos, tarde o temprano llega la necesidad de tener que preparar scripts para actualizar el modelo de datos en el cliente, en un servidor no accesible, etc. Esto trae una carga importante de riesgos, sobre todo de pérdida de información o de dejar la base en un estado inconsistente.

Para asegurarnos de que todo quede en un estado conocido, en principio podemos abrir una transacción y poner todo el script en un bloque TRY-CATCH como este:

BEGIN TRY
    BEGIN TRANSACTION
    --
    -- Poner acá el script con los cambios de la base
    --
    -- Aceptar los cambios de la transacción
 
    COMMIT TRANSACTION
END TRY
 
BEGIN CATCH
    -- Deshacer los cambios de la transacción
    ROLLBACK TRANSACTION
    --
    -- Manejar el error o relanzarlo
    --
END CATCH

Ahora, supongamos que nuestros cambios son los siguientes:

CREATE TABLE Sucursales (
    IdAlmacen INT,
    Direccion VARCHAR(100)
)
GO
 -- Otros cambios
GO
 
DELETE Articulos
WHERE IdCategoria = 9999
GO
 
-- Cambios sensibles y peligrosos
GO
CREATE PROCEDURE HacerNegocios AS
BEGIN
    --
    -- Aca va la formula mágica de cada uno
    --
END
GO
 
-- ...mas cambios peligrosos!
GO

 

Para ponerlo dentro del bloque TRY-CATCH, la única consideración seria borrar los "GO" ya que sino la transacción y el TRY quedarían incompletos, y el script no ejecutaría correctamente.

Nota: La palabra "GO" no es parte del lenguaje TSQL sino un comando (bastante estándar) interpretado por las aplicaciones como un separador de lotes de instrucciones. Para mas información: http://msdn.microsoft.com/es-es/library/ms188037.aspx .

Con esto surge un problema, el CREATE/ALTER PROCEDURE (también aplicado a Functions y Triggers) debe ser la primera instrucción del lote debido a una restricción de sintáxis de SQL Server

Para salvar este inconveniente, una solución es ejecutar la creación del stored procedure con Dynamic SQL. Quedando asi:

EXEC(N'CREATE PROCEDURE HacerNegocios AS
BEGIN
    --
    -- aqui va la formula magica de cada uno
    --
    SELECT * FROM CC
END')

Con esto, no hay ningún problema de crear o modificar un stored procedure dentro de una transacción.

BEGIN TRY
    BEGIN TRANSACTION
    
    CREATE TABLE Sucursales (
    IdAlmacen INT,
    Direccion VARCHAR(100)
    )
 
    -- Otros cambios
 
    DELETE Articulos
    WHERE IdCategoria = 9999
 
    -- Cambios sensibles y peligrosos
 
    EXEC(N'CREATE PROCEDURE HacerNegocios AS
    BEGIN
        --
        -- aqui va la formula mágica de cada uno
        --
    END')
 
    -- ...mas cambios peligrosos!
    
    -- Aceptar los cambios de la transacción
    COMMIT TRANSACTION
END TRY
BEGIN CATCH
    -- Deshacer los cambios de la transacción
    ROLLBACK TRANSACTION
 
    --
    -- Manejar el error o relanzarlo
    --
END CATCH
 

Espero que este pequeño "truco" facilite la generación de scripts para hacer actualizaciones en las bases de datos.

SQL Server , ,