Contenedor de Inversión de Control – Unity 3.0 para ASP.NET MVC

Saludos.

Continuamos con los contenedores de inversión de control, en esta oportunidad nos vamos a centrar en Unity.mvc, el contenedor oficial de Microsoft creado por el equipo Patterns & Practices para proyectos ASP.NET MVC.

Instalación

Para instalar el componente usamos Nuget, ya sea desde la interfaz gráfica o la consola de instalación.

 PM> Install-Package Unity.mvc

Una vez finalizada la instalación del paquete podemos ver que se han creado un par de archivos en la carpeta App_Start: UnityConfig.cs y UnityMvcActivator.cs. En el primero de ellos encontramos la configuración de contenedor, el punto en el que registraremos nuestras clases e interfaces para posteriormente usarlas en la resolución de dependencias. En UnityMvcActivator.cs, se encuentra el código de inicialización específico de la integración para ASP.NET MVC, usando el componente WebActivatorEx, una útil herramienta que permite introducir módulos de forma dinámica, durante el arranque.

Registro de componentes

El registro de interfaces y clases se lo realiza sobre el contenedor Unity. Para ello, nos dirigimos al archivo UnityConfig.cs e implementarlo de la misma forma que siempre:

public static void RegisterTypes(IUnityContainer container)
{
 // container.LoadConfiguration();
 
 // TODO: Registrar los tipos aqui
 
 container.RegisterType<IUnitOfWork, UnitOfWork>(new TransientLifetimeManager(), 
 new InjectionConstructor(connectionString.ConnectionString));

 // container.RegisterType<IUsuariosRepository, UsuariosRepository>();
 // container.RegisterType<IMascotasRepository, MascotasRepository>();
 
 container.RegisterType<IUsuariosAppServices, UsuariosAppServices>(new ContainerControlledLifetimeManager());
 container.RegisterType<IMascotasAppServices, MascotasAppServices>("SingletonMascota", new ContainerControlledLifetimeManager());
 container.RegisterType<FuenteDigital>(new ContainerControlledLifetimeManager(), 
 new InjectionProperty("Id", objeto.Id), new InjectionProperty("Name", objeto.Name));

}

Así podemos ir registrando cuantos pares interfaz-clase necesitemos en la aplicación.

Instancias Per request

Una de las características importanes en Unity 3.0 y su integración con MVC es la gestión del ciclo de vida de las instancias per request. Los que antes se tenia que pensar en vincular las instancias a un contenedor padre usando HierarchicalLifetimeManagers o sobrescribir manualmente el método Dispose() para que éste fuera liberado una vez termine la petición, ahora podemos ir al grano registrando los componentes y/o clases de forma PerRequestLifetimeManager, con esto hacemos que las instancias sean únicas por cada request o petición, ahorrando recursos y/o memoria.

public static void RegisterTypes(IUnityContainer container)
{
 // container.LoadConfiguration();
  container.RegisterType<IUsuariosRepository, UsuariosRepository>(new 
   PerRequestLifetimeManager());
  container.RegisterType<IMascotasRepository, MascotasRepository>(new 
   PerRequestLifetimeManager());
}

Para que esto sea posible y las instancias sean liberadas correctamente al finalizar la petición, en el archivo UnityMvcActivator.cs que Nuget ha dejado en la carpeta App_Start:

public static void Start() 
{
 var container = UnityConfig.GetConfiguredContainer();
 //....
 //....

 // TODO: Uncomment if you want to use PerRequestLifetimeManager
 // Microsoft.Web.Infrastructure.DynamicModuleHelper.DynamicModuleUtility
 // .RegisterModule(typeof(UnityPerRequestHttpModule));
}

Simplemente descomentamos la llamada a RegisterModule() del final y las instancias serán liberadas al finalizar la petición de forma automática, lo que antes lo hacíamos con los Dispose(), ahora Unity nos ahorra el trabajo de hacerlo automáticamente.

Convenciones

Otras de las características importantes que tiene Unity 3.0 son las convenciones, el poder registrar los componentes basándonos en convenciones es mucha dosis, nos ahora bastante trabajo a la hora de hacer el mantenimiento. Para lograr ésto, debemos decirle a Unity que debe usar la convención de nombrado para interfaces y clases con nombres equivalentes, aquí un ejemplo:

public static void RegisterTypes(IUnityContainer container)
{
 container.RegisterTypes(
 AllClasses.FromAssemblies(typeof(MvcApplication).Assembly),
 WithMappings.FromMatchingInterface,
 WithName.Default, 
 WithLifetime.Custom<PerRequestLifetimeManager>
 );
}

Con ésto ya no tendremos que asociar mil interfaces del tipo IMyComponent a la clase MyComponent. Por supuesto, estas convenciones son configurable y puedes conocer mas en el sitio oficial de Unity.

Espero esta publicación te sirva como una introducción al contenedor Unity, sin duda puedes encontrar ejemplos avanzado en la pagina oficial, lo importante es que vayas conociendo algunas herramientas que facilitan el proceso y gestión del ciclo de vida de los componentes.

Saludos.

Contenedor de Inversión de Control – IoC Container

En esta oportunidad quiero compartirles sobre los contenedores de inversión de control (IoC Containers). Uno de los puntos a tomar en cuenta durante el desarrollo de sistemas es reducir el acoplamiento entre componentes, mientras mas bajo sea éste, menos esfuerzo realizamos durante el proceso de integración de los mismos, además estar preparados ante cualquier cambio que puedan surgir.  Uno de los principios SOLID que nos ayudan para lograr este objetivo es el Principio de Inversión de Dependencia y las técnicas de Inyección de Dependencias, acompañados con los magníficos contenedores de inversión de control.

Un Contenedor de Inversión de Control (IoC Container) es un componente especializado en la creación de instancias de objetos, así como en la gestión del ciclo de vida éstas, en términos simples es una clase encargada de suministrarnos las instancias que necesitemos en nuestra aplicación y olvidar sus dependencias hacia otras clases. ¡Fabuloso!. Nos olvidamos de los molestos «new» cada vez que necesitemos una instancia de alguna clase, por supuesto requiere una configuración inicial donde registramos todas las clases.

Los contenedores de inversión de control se apoyan en dos conceptos muy importantes Inyección de Dependencia e Inversión de Control, muchos creen que son lo mismo pero son dos conceptos diferentes que comparten cosas en común.

Inyección de Dependencia (DI)

  • Es un patrón de diseño que consiste en hacer que nuestras piezas de Software sean independientes.
  • Se refiere a la forma de como implementar el patrón IoC.
  • Se refiere a la forma de como los objetos consumidores reciben sus dependencias

Inversión de Control (IoC)

  • Patrón de diseño que coadyuva al bajo acoplamiento entre componentes de un sistema o una aplicación.
  • Los objetos consumidores no crean los objectos ayudantes, de los que depende. Estos son creados por un contenedor (Ejem: Unity Conteiner), que inyectará las dependencias. Útil para implementar un sistema enfocado a un diseño orientado a componentes.

Ahora vamos a ver uno de los contenedores mas usados dentro de la plataforma .NET, si aún no lo conoces es momento de hacerlo e iniciar el desarrollo de tus proyectos usando esta herramienta.

Unity (By Microsoft)

Éste IoC Container fue creado por Microsoft Pattern & Practices.

unity

Unity tiene licencia MS-PL Licence. Fue escrito por Chris Tavares y su “Kernel” está basado en ObjectBuilder.

Aquí puedes ver como puedes iniciar la configuración del contenedor y registrar las clases.

public class Bootstrapper
{
private IUnityContainer unityContainer;
public Bootstrapper()
{
unityContainer = new UnityContainer();
unityContainer.RegisterType<IPasswordCipher, Pbkdf2PasswordCipher>(new ContainerControlledLifetimeManager());
unityContainer.RegisterType<IPasswordCipherFactory, Pbkdf2PasswordCipherFactory>(new ContainerControlledLifetimeManager());
var cipherPassword = unityContainer.Resolve<IPasswordCipher>();
var cipherPasswordFactory = unityContainer.Resolve<IPasswordCipherFactory>();
// Usamos los objetos instanciados
var cifrado = cipherPassword.Encryp("password");
}
}

Si bien este es un ejemplo sencillo, mas adelante estaré compartiendo las distintas configuraciones que puedes realizar, inyectar constructor y la configuración de los tiempos de vidas de los objetos.

Espero sea de utilidad y puedas aplicarlos en tus proyectos.

Saludos y hasta pronto.

Presentacion Tips Team Foundation Server

Les comparto otras de las presentaciones a los interesados en una introducción sobre  Tips de Team Foundation Server, un servicio de gestión del ciclo de vida proyectos de SW, con el que podrás realizar no sólo el control de versión de tu aplicación, sino también el seguimiento de tareas realizadas y por hacer, asignacion de tareas entre los miembros de un equipo de desarrollo, etc.

Si estas interesado en una presentación del contenido del curso, puedes escribirme a: uialberto@outlook.com

Saludos.

 

01Principio de Responsabilidad Simple – SOLID

Saludos.

Iniciamos una serie de publicaciones sobre los principios SOLID. Los principios S.O.L.I.D. son un conjunto de diseños y buenas prácticas que se emplean en OOD y OOP (diseño y programación orientada a objetos). Estos principios fueron desarrollados y publicados por primera vez por Robert “Tío Bob” Martin hace más de una década. En esta oportunidad detallaremos el primero de los principios, el Principio de Responsabilidad Simple. Este principio nos dice:

«There should never be more than one reason for a class to change»

«No debe existir mas que una sola razón para que una clase cambie»

El punto es que todos los atributos y todas las operaciones de una clase deben estar intrínsecamente relacionados con un solo propósito. Si se encuentra que al modificar una clase tiene dos responsabilidades se debe separar en dos clases respectivamente. Una clase que hace muchas cosas, es muy grande o muy complicada de seguro tendrá mas de una sola responsabilidad.

Para comprender mejor este principio vamos a ejemplificar mediante un diseño de clases.

Diagrama Clases - Violación al Principio de Responsabilidad Simple
Diagrama Clases – Violación al Principio de Responsabilidad Simple

 

El anterior diagrama muestra la violación del principio de responsabilidad simple ya que vemos que la clase Cuenta tiene más de una responsabilidad, esto se lo puede verificar mediante el método Transferir. Si bien tiene sentido que podamos transferir dinero de una cuenta a otra, vemos que se viola este principio al darle la responsabilidad a la clase Cuenta para dicho propósito. Esta operación debe ser sacada de la clase y llevada a otra que podemos  llamar por ejemplo ServicioTransferencia, así nuestra clase Cuenta solo tendría operaciones relacionadas a ella misma.

Veamos como seria una posible solución a la violación del Principio de Responsabilidad Simple.

Solución a Violación al Principio de Responsabilidad Simple
Solución a Violación al Principio de Responsabilidad Simple

 

Mediante este nuevo diseño podemos verificar la única responsabilidad para cada clase. Se ha delegado la responsabilidad a la clase ServicioTransferencia de Transferir dinero de una cuenta origen a una cuenta destino.

Ventajas de Aplicar este principio

  • Código más fácil de escribir y de entender.
  • Menos propenso a errores, ya que cada clase tiene una única responsabilidad bien definida
  • Facilita las tareas de testing : tenemos bien definido que debemos testear en cada clase.
  • Facilita las tareas de mantenimientos
  • Hace que nuestro código sea más robusto y extensible.

Espero les sea de utilidad.

 

 

02 Principio de Abierto/Cerrado – SOLID

Saludos.

Volviendo con las publicaciones de los principios SOLID, hoy veremos el Principio de Abierto/Cerrado (OCP).

Todas las aplicaciones cambian durante su ciclo de vida, ya sea esta por nuevos requerimientos, alguna mala identificación de los requerimientos o por el simple hecho que el cliente así lo requiera. Este principio nos ayuda a estar preparados para estas posibles situaciones, evitando así y reduciendo el impacto a futuros cambios.

El Principio Open/Closed (Open/Closed Principle, OCP) fue presentado por el Dr. Bertrand Meyer en su libro «Object Oriented Software Construction» y afirma que:

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

«Las entidades del software (clases, módulos, funciones, etc.) deben estar abiertas para la extensión pero cerrados para la modificación»

 Para comprender mejor este principio vamos a ejemplificarlo por medio de un diseño.

Diagrama clases – Explicación del Principio Abierto/Cerrado
Diagrama clases – Explicación del Principio Abierto/Cerrado

El diagrama anterior es un ejemplo de una clase que rompe con el principio abierto/cerrado (OCP). Vamos a suponer un sistema de gestión de proyectos, de tal manera nos vamos a centrar en la entidad Tarea y vamos a descubrir como rompe con el principio abierto/cerrado.

Como se puede observar en las relaciones dicha clase viene determinando por uno de los estados de la enumeración EstadoTarea (Pendiente, Finalizada, Cancelada), además se puede observar que la clase implementa 3 métodos, Iniciar, Cancelar y Finalizar que cambian si es posible el estado de la tarea. Veamos como sería una posible implementación del método Finalizar.

Violación al Principio de Abierto/Cerrado
Violación al Principio de Abierto/Cerrado

Al parecer esta implementación no esta nada mal, de hecho no esta nada mal si no se agregarán nuevos estados :), pero como comentamos al inicio, «todas las aplicaciones cambian durante su ciclo de vida».

Supongamos entonces un nuevo requerimiento o cambio típico solicitado por el cliente de la aplicación, el cual sería la adición de un nuevo estado para controlar las tareas que se han Propuesto, con lo que la implementación de este método podría ser:

Violación al Principio de Abierto/Cerrado
Violación al Principio de Abierto/Cerrado

Aparentemente, parece una modificación trivial pero este cambio puede involucrar muchos otros, en los métodos y/o clases donde se utilice la enum EstadoTarea, no olvidemos que este nuevo cambio nos haría modificar también la implementación del método Cancelar.

Violación al Principio de Abierto/Cerrado
Violación al Principio de Abierto/Cerrado

Vemos claramente, por cada nuevo estado que implementemos tendremos que identificar la implementación para todas las clases que lo utilizan y modificarlas, violando el principio Abierto/Cerrado (OCP).

A continuación planteamos una solución a la violación del principio utilizando el patrón State.

Solución a violación del Principio Abierto/Cerrado
Solución a violación del Principio Abierto/Cerrado

Básicamente, lo que se ha hecho es crear una clase por cada estado en lugar de tener una única clase cuyos métodos están basados en sentencias condicionadas por el estado de la tarea. Además, con esta nueva implementación se ha delegado la responsabilidad de finalizar, cancelar o posponer a una nueva clase BaseEstadoTarea que que se ha marcado como abstracta. La clase Tarea implementará sus propios métodos y delegará la responsabilidad a través de las clases TareasEstados que heredan de BaseEstadoTarea. Debido a que la clase Tarea gira en torno a un estado, asumimos que el estado inicial por defecto es Pendiente, y así se deberá especificar en el constructor, instanciando a TareaEstadoPendiente.

Vamos a ver como seria la implementación para esta solución.

Implementación de la Solución con el patrón State
Implementación de la Solución con el patrón State

Ante un nuevo requisito en el que intervenga un nuevo estado, lo único que se deberá hacer es crear una nueva clase que herede de BaseEstadoTarea e implementar los métodos virtuales, extendiendo así el comportamiento de la aplicación sin comprometer el código existente.

Espero le sea de utilidad.

Articulo extraido de http://www.programacion.com
 
 

03 Principio de Sustitución de Liskov – SOLID

Saludos.

Volviendo con las publicaciones de los principios SOLID. Hoy veremos el Principio de Sustitución de Liskov (LSP).

Si bien existen varios ejemplos en la web en la que podemos comprender de que trata este principio, me he quedado con este por ser un caso real en la que se puede presentar.

Revisemos el enunciado de Robert C. Martin.

«Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.» — Robert C. Martin

«Las funciones que utilicen punteros o referencias a clases base deben ser capaces de usar objetos de clases derivadas de éstas sin saberlo.»

Aún no quedo claro. ¿Verdad?

Si has comprendido el enunciado en tu primera lectura y no es necesario una explicación mas detallada al respecto, entonces eres genial. 🙂

 Pero existen varias definiciones al respecto, aquí algunas de ellas:

  1. Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas.
  2. Toda subclase debe soportar ser sustituida por su clase base lo que en términos de contratos significa que las precondiciones de los métodos de la subclase no serán más fuertes que las de la clase base, y sus pos condiciones no serán más débiles (en términos criollo: los métodos derivados no deben esperar más ni proveer menos que los originales).
  3. Las clases derivadas deben ser utilizables a través de la interfaz de la clase base, sin necesidad de que el usuario conozca la diferencia.

Claramente nos describen la importancia con respecto a crear clases derivadas y que estas deben ser tratadas como la clase base, es decir cuando creamos clases derivadas, hay que asegurarse de no reimplementar métodos que hagan que los métodos de la clase base no funcionen bien si al crear un objeto de la clase derivada se tratase como si fuera de la clase base. Para que se comprenda mejor, veamos el siguiente diagrama.

Principio de Substitución de Liskov
Diagrama clases – Explicación del Principio de Substitución de Liskov

Problemas:

Problema que rompre el 3er Principio SOLID
Violación al Principio de Substitución de Liskov

Tenemos un claro caso de violación del LSP con respecto a la definición 1, ya que la ejecución del método CalcularImpuesto generará una excepción de conversión de tipo si el objeto pasado por parámetro es de tipo Ciclomotor en lugar de Coche, pese a que ambas clases derivan de la misma clase base Vehículo.

Violación al Principio de Substitución de Liskov
Violación al Principio de Substitución de Liskov

Pese a que el compilador no genere ninguna excepción de conversión de tipo, esta clase aún viola el LSP. Esto es debido a que estamos forzando a un objeto Vehículo pasado como parámetro a comportarse como Ciclomotor o Coche.

Solución:

Solución a Violación del Principio de Sustitucion de Liskov
Solución a Violación del Principio de Sustitucion de Liskov

Agregamos un método virtual a la clase Vehiculo CalcularImpuesto que será reimplementado de acuerdo a la lógica requerida en cada una de las clases derivadas, así cuando la clase Impuesto requiera el cálculo en cada una de ellas pueda llamar al método implementado.

Implementación de la Solución a violación del LSP
Implementación de la Solución a violación del LSP

 

Es posible aplicar otras soluciones a este problema por medio del uso de interfaces, pero esto lo dejamos para futuras publicaciones.

Que sea de utilidad.

Hasta pronto.

04 Principio de Segregación de Interfaces – SOLID

Saludos.

Después  de mucho tiempo de ausencia en el Blog, hoy continuamos con los principios SOLID. En esta oportunidad quiere recordarle la importancia del Principio de Segregación de Interfaces. Fué introducido por el propio Robert Martin, veamos su definición:

Clients should not be forced to depend upon interfaces that they do not use.

Clientes no deben ser forzados a depender de interfaces que no usen.

Para una mejor comprensión se muestra a continuación un diagrama en el cual se tiene el problema del 4to principio SOLID.

11-07-2013 23-41-10
Problema que rompe el 4to principio SOLID

 

Problema: Como podemos ver en el diagrama de clases. Se tiene una interfaz IProceso que define las firmas: Iniciar, Suspender, Reiniciar, Finalizar para todo proceso. Así mismo tenemos una clase ProcesoManual y ProcesoAutomatizado que implementa la interfaz IProceso. Aquí vemos claramente como se rompe el 4to principio SOLID, ya que no debería existir implementacion de los métodos Reiniciar y Finalizar de la clase ProcesoAutomatizado ya que todo proceso automatizado no se reinicia ni finaliza su actividad. Entonces rompemos la regla: Clientes no deben ser forzados a depender de interfaces que no usen.

Para esto se debería aplicar la siguiente solución.

12-07-2013 0-05-48
Solución Aplicando el 4to Principio SOLID

 

La clase ProcesoAutomatizado solo implementa la interfaz IProceso, ya que mencionamos anteriormente no debería conocer ni implementar las firmas de la interfaz IManual, siendo que esta interfaz solo va ser implementada por ProcesoManual.

Con esto vemos que las clases cliente no implementa interfaz o firmas de la interfaz que no sean necesarias para su implemetación.

Que sea de ayuda para ti.

Saludos.

 

Aggregate y Aggregate Roots – DDD

Saludos mis amigos.

Uno de los conceptos más utilizados dentro de la arquitectura DDD son los Agregados. He buscado documentación sobre   estos conceptos y encontré un artículo muy bueno que describe de manera sencilla y con ejemplos que son estos elementos.

Domain Driven Design
Domain Driven Design

En el dominio de un sistema hay cosas que inevitablemente deben ir juntas de la mano. Un Aggregate es precisamente ese conjunto de cosas. Un Aggregate Root es una Entidad (de las que ya hemos hablado) que mantiene unido y coherente dicho conjunto.

Un sencillo ejemplo

En un sistema de ventas, un Cliente puede tener una referencia a los Pedidos de ese cliente y un pedido debe tener referencia a las Líneas del Pedido (ítem, cantidad, precio del ítem, etc).

Se puede observar que un Pedido no tiene sentido sin un Cliente que haya realizado ese Pedido, y una Línea de Pedido no tiene sentido sin el Pedido. Son conceptos que van de la mano y por tanto se puede deducir que Cliente y Pedido es un aggregate y que Pedido y LineaDePedido es otro aggregate.

Ahora debemos deducir cual seria el aggregate root. Para esto, solo tenemos que mirar cual es la Entidad principal que actuaría de «punto de entrada», o la entidad desde la cual «tiramos del hilo» para realizar las operaciones.

En este ejemplo está claro que la raíz de uno de los agregados es Cliente y la raíz del otro es Pedido. También se puede observar que, aunque Pedido actúa como root de LineaDePedidos, al ser éste un hijo de Cliente, no se considerará aggregate root principal para los repositorios del dominio.

¿Y todo esto para que?

La característica principal de un aggregate root es que actúa como un ente único que controla el acceso a sus hijos. Gracias a esto se mantiene la coherencia del conjunto. Básicamente provee un patrón para mantener la lógica de dónde pertenece realmente un ítem.

Es la entidad raíz la que expone las acciones a realizar para con sus hijos. Es el Cliente el que expone una acción para realizar un nuevo Pedido (Cliente.RealizarNuevoPedido) o para cancelarlo (Cliente.CancelaPedido). Esto nos permite encapsular las reglas y restricciones del dominio.

Si una restricción nos dice que un Cliente sólo puede tener 3 Pedidos abierto a la vez, es responsabilidad del Cliente (en la acción Cliente.RealizarNuevoPedido) el contar cuántos Pedidos tengo abiertos; si no llego al máximo debo realizar el nuevo pedido, y si no puedo realizar más pedidos debo notificarlo de alguna manera y no realizar el nuevo pedido.

Se aplica un caso parecido con respecto a Pedidos y LineasDePedido.

Otra característica que deben cumplir los aggregate root es que son las únicas entidades que retornan los repositorios. Nunca se debería poder obtener de la capa de persistencia un Pedido directamente. Debo obtener el Cliente y «tirar del hilo» para llegar al Pedido, o seguir «tirando del hilo» para llegar a una Línea de Pedido. Hay que «navegar» a través de las entidades raíces.

No dejéis que os engañe un experto del dominio que diga, por poner un ejemplo chorra, que hay que listar todos los Pedidos abiertos en el sistema independientemente del Cliente para que un operador les de el visto bueno o los marque como erróneos. Dado que es probable que por otro lado se necesite bloquear a un Cliente la capacidad de realizar un nuevo Pedido (debido a problemas con un cobro, una tarjeta de crédito bloqueada o cualquier otra cosa), una forma correcta de enfrentar esto sería recuperar del repositorio todos los Clientes que tengan algún Pedido abierto y mostrar esos Pedidos por pantalla. Cuando el operador los marcase como correctos, deberíamos utilizar una acción expuesta por el Cliente (Cliente.AceptarPedido) que aplicara las reglas y restricciones para con los Pedidos según el estado actual de ese Cliente.

En resumen

Los aggregates proveen un agrupamiento lógico de Entidades y Objetos-Valor. El aggregate root actúa de punto de entrada para ese conjunto, encargándose de las normas y restricciones que deban cumplir las colecciones de hijos.

Fuente: Articulo Original Agregados

Espero sea de utilidad.

Saludos.

Database First vs Model First vs Code First – Entity Framework

Saludos.

Para comenzar a trabajar con Entity Framework, podemos hacerlo mediante 3 enfoques diferentes para crear nuestro modelo conceptual.

Entity Framework - Modelo
Entity Framework – Modelo

Database First

El modelo conceptual se crea a partir de una base de datos existente.

Model First

Se crea el modelo conceptual y se genera la base de datos.

Code First

Nuevo a partir de EF 4.1. Un enfoque simplificado que permite mapear nuestras clases POCO a la base de datos usando convención, Data Annotations o Fluent API.

Que sea de utilidad.

Enlaces:

http://gustavoazcona.blogspot.com/2011/07/entity-framework-code-first.html

http://gustavoazcona.blogspot.com/2011/06/entity-framework-database-first.html

http://gustavoazcona.blogspot.com/2011/07/entity-framework-model-first.html

Saludos.

Objetos POCO, DTO – Entity Framework

Buenas mis amigos.

Hace ya varios días que vengo familiarizándome con la herramienta de Entity Framework. Cada día me encuentro con nuevos términos,  definiciones y nuevas tecnologías. Por lo que he decidido comenzar a tomar apuntes de todos ellos que se me presenten de ahora en adelante.

POCO – Plain Old CLR Object

Son las siglas de Plain Old C# Object, y se refieren a «clases simples» que no dependen de ninguna Framework. Es un término derivado del concepto del mundo Java: POJO. El término POCO se utiliza para contrastar un objeto «estándar» o simple de un objeto que está diseñado para ser utilizado con un complicado Framework de objetos, tal como un ORM, o bien para diferenciarlo de un objeto COM.

DTO – Data Transfer Object

Se refiere a Data Transfer Objects y es un objeto que por definición se envía y recibe dentro de un servicio (WS, WCF).  Básicamente son un molde para la información, donde el esquema se encuentra fuertemente tipeado.

Algunas de las ventajas de utilizar diseños que implementen este tipo de objetos son:

  • En cualquier punto del sistema la información puede ser validada, a partir de metadatos establecidos.
  • Mejora la comunicación entre los programadores, dándoles un mismo esquema de información, evitando conflictos.
  • Separa físicamente las capas del sistema, haciendo el código mucho mas limpio y reutilizable.
  • Proporciona mayor seguridad.

Aunque estos objetos pueden darnos una gran cantidad de ventajas, tienen una enorme desventaja la cual es la causante de su poco uso, y es el tiempo de desarrollo, ya que obliga al programador a tipear cada una de las entidades lógicas del sistema.

Una de las preguntas interesantes en el Grupo de Arquitectos .NET :

Que utilizariais para devolver la información en un servicio WCF donde en la capa de datos se esta ultilizando Entity Framework.

DTO o POCO?

Los objetos POCO contienen las propiedades de navegación.

Las respuestas la encontramos en un articulo escrito mas tarde por uno de los participantes basado en los comentarios y opiniones de miembros del Grupo:  Sobre WCF, DTO, POCO

Espero sea de utilidad.

Saludos.