Desarrollo de Software

Articulos generales sobre desarrollo de software

Automapper y un buen articulo de diseño de software

Logo AutoMapper

La semana pasada descubrí AutoMapper, que es un proyecto de .NET gratis y open-source de Jimmy Bogard.

Un desarrollador de la oficina me preguntó si había una manera integrada en el framework de transformar las clases generadas por LINQ-To-SQL en clases sencillas (DTOs). No creí que lo hubiera…pero le comenté que seguramente lo podía hacer por Reflection. Yo ya habia hecho eso antes, pero supuse que debía haber alguna mejor manera. Después de buscar un poco en StackOverflow.com, alguna de las respuestas linkeaba a AutoMapper y descubrí que era exactamente lo que aquel desarrollador estaba buscando.

AutoMapper es descrito en su página principal de la siguiente manera:

AutoMapper uses a fluent configuration API to define an object-object mapping strategy. AutoMapper uses a convention-based matching algorithm to match up source to destination values. Currently, AutoMapper is geared towards model projection scenarios to flatten complex object models to DTOs and other simple objects, whose design is better suited for serialization, communication, messaging, or simply an anti-corruption layer between the domain and application layer.

Excelente…no solo utiliza interfaces fluidas, sino que también se basa en Convention Over Configuration. Es decir…solo tenemos que (y podemos!) configurar las situaciones excepcionales. Las ventajas que le veo a utilizar AutoMapper (a pesar de estar incorporando una referencia más a nuestros proyectos) es que es un proyecto público (de open source) y que además tiene a un muy buen desarrollador respaldándolo, que por ser su proyecto, se enfoca en mejorarlo y perfeccionarlo con nuevas funcionalidades, haciéndolo más eficiente, etc. Además, debido a que ya tiene una considerable base de usuarios (3,702 downloads), la mayoría de los bugs que pudiéramos toparnos, ya han sido resueltos.

Un ejemplo exagerádamente básico del uso de AutoMapper:


public class Class1
 {
   public string FullName { get; set; }
   public int Age { get; set; }
   public char Gender { get; set; }
   public void DoIt()
   {
     Console.WriteLine("Test");
   }

   public List<string> Addresses { get; set; }

   public Class1()
   {
     Addresses = new List<string>();
   }
 }

 public class Class2
 {
   public string FullName { get; set; }
   public int Age { get; set; }
   public char Gender { get; set; }
 }

private void Form1_Load(object sender, EventArgs e)
{
   Mapper.CreateMap<Class1, Class2>();

   var c2 = Mapper.Map<Class1, Class2>(c1);
   MessageBox.Show(c2.FullName);
}

Ok, de este ejemplo podemos ver:

  • Class1 es poco más compleja que Class2, ya que tiene una List<string> y un método definido (DoIt())
  • Class2 es una versión simple de Class1, con el objetivo de funcionar como un Data Transfer Object.

Como pueden ver, con la instrucción:

Mapper.CreateMap<Class1, Class2>();

estamos indicándole a AutoMapper que la Class1 y Class2 están relacionadas (mappeadas). Y la siguiente línea de código:

var c2 = Mapper.Map<Class1, Class2>(c1);</pre>

está creando una instancia de tipo Class2, basada en la instancia de c1 que ya teníamos, inicializada y asignando dinámicamente los valores de dicha instancia (c1) a la nueva instancia c2.

Class1, en este caso, sería un ejemplo de una clase de LINQ-To-SQL, mientras que Class2 sería la clase que queremos usar como DTO.

Esta funcionalidad es sólamente la más básica de AutoMapper (flattening). También soporta proyecciones (utilizar ciertas propiedades o sub-sets de un valor para mapear a otra propiedad), Listas y Arrays, etc. Para más información, visisten la documentación de AutoMapper.

Y sobre el buen artículo de diseño…para mi sorpresa lo encontré 2 dias después de haber descubierto AutoMapper, y el artículo lo escribió Jimmy Bogard.

El artículo se llama originalmente “Strengthening your domain: Encapsulated collections“. Jimmy habla de como debemos de diseñar nuestras clases para no exponer inadvertidamente funcionalidad de más (extra, innecesaria) que podría permitir operaciones no lógicas sobre nuestras entidades, y enfocarnos en soportar exclusiva y claramente sólo las operaciones que el dominio de negocio debe permitir sobre las entidades de nuestro proyecto. El artículo también me hizo pensar que los accesors son algo que mucha gente no considera a la hora de exponer sus propiedades. Léanlo y si gustan dejar sus comentarios…adelante.

Aplicar formatos condicionales a numeros con string.Format

.NET

Esto es algo que descubrí hoy referente a formateo de números en .NET y que por más simple que parezca, tiene mucha utilidad, ya que puede reducir un bloque de 3 o 6 líneas de código, a una sola línea.

En lugar de necesitar varios if’s para evaluar el valor del número que vamos a formatear y poder determinar el formato que se va a aplicar (desplegar el número entre paréntesis si es negativo, desplegar la palabra Cero si el número es 0, etc), se puede hacer todo el una sola línea, ya que el metodo ToString() permite formatos condicionales de 2 o 3 condiciones…es decir, podemos hacer esto:


const string formato = "000;(##);Cero";

 Console.WriteLine(7.ToString(formato)); // va a desplegar "007"
 Console.WriteLine((-5).ToString(formato)); // va a desplegar "(5)"
 Console.WriteLine(0.ToString(formato)); // va a desplegar "Cero"

Formatos condicionales en .NET usando ToString()

Formatos condicionales en .NET usando ToString()

El formato entonces es:  “positivo;negativo;cero”.

También es posible especificar solo el formato positivo y negativo.

Espero les sirva.

Cursos de Visual Studio 2010 y .NET Framework 4.0 gratis

Channel 9 Logo

Channel 9 Logo

La gente de Channel 9, uno de los mejores sites para aprender de desarrollo y especificamente de .NET, acaba de abrir una sección nueva llamada Channel 9 Learning Center.

Para inaugurar la sección, publicaron dos cursos iniciales:

Visual Studio 2010 Logo

Visual Studio 2010 Logo

La calidad del contenido que este site genera es buenísima. Los videos siempre son interesantes, y las personas que conducen y son entrevistadas en los videos siempre es gente importante y muy conocedora de la industria.

Algunos de los temas del curso de Visual Studio 2010 son:

  • ASP.NET 4.0
  • Data Platform
  • Application Lifecycle Management
  • Windows Communication Foundation and Workflow
  • Managed Languages

Así que si no se quieren quedar obsoletos…vayan a aprovechar este material. Las mejoras en el .NET Framework 4.0 son muchas, y esta version implica cambio de CLR…así que hay mucho que aprender.

Principios de Diseño Orientado a Objetos (OOD)

Siguiendo con esas cosas que todos deberían saber…pero que muchos no comprenden totalmente:

Robert Martin, mejor conocido como Uncle Bob, explica de manera muy clara los principios básicos de diseño orientado a objetos. No solo es necesario poder recitar estos principios, sino que hay que entenderlos y poder explicar las razones de su importancia.

Precisamente de este articulo que voy a poner la liga, cito un párrafo que es muy cierto:

“All too often today’s programmers are unaware of the principles that are the foundation of the disciplines that their languages were derived around.”

Los primeros 5 principios son los famosos SOLID (que en muchas ocasiones les tocará leer el acrónimo en artículos) y son orientados a diseño de clases. Los 3 siguientes son orientados a Cohesión de librerías de código, y los últimos 3 son orientados a dependencias entre librerías de código.

Los principios SOLID:

  • Single Responsibility Principle (SRP)
  • Open-Closed Principle (OCP)
  • Liskov Substitution Principle (LSP)
  • Interface Segregation Principle (ISP)
  • Dependency Inversion Principle (DIP)

Incluso cada uno de los principios está claramente explicado y disponible para bajarse en PDF por separado. La siguiente es la liga:

The principles of Object Oriented Design, by UncleBob

1 2 3 4 5 6 8  Scroll to top