Qué es MEF y que te aporta

MEF es una tecnología que permite desarrollar aplicaciones extensibles. La gran ventaja que nos ofrece MEF es que no necesitamos diseñar la aplicación conociendo qué extensiones formaran parte de ella ni la implementación interna de las propias extensiones.

Por extensible nos referimos a que nuestra aplicación puede estar en producción y de forma dinámica añadir, reemplazar, eliminar las extensiones que tenemos sin necesidad ni de recompilar ni reiniciar la aplicación.

MEF viene con .NET Framework 4 en la librería: System.ComponentModel.Composition.

MEF vs IoC Container

Aunque pueda parecer que MEF e IoC ofrecen la misma funcionalidad la diferencia consiste en que tratan de resolver problemas distintos.

El objetivo básico de un framework de IoC es el de ofrecer desacoplamiento entre componentes y nos resuelve dependencias que conocemos. Esto nos permite que nuestra aplicación sea modular y testeable.

En cambio, en MEF, el principal objetivo es la extensibilidad: el desacoplamiento es una consecuencia. Sabemos que las extensiones que se vayan a implementar cumplirán un contrato pero no sabremos si sólo habrá una extensión, muchas o ninguna.

Ejemplo: Extensión IHelloWorld

Ver Más

En el último post acerca de le herencia en Entity Framework 4 y Code Only, vamos a ver la estrategia de Table per concrete Class (TPC).

La diferencia con las estrategias de los ejemplos anteriores: Table per Hierarchy y Table per Type es que, en este caso, la clase base no tiene ningún tipo de representación en las base de datos y sólo tiene sentido a nivel de clases del modelo.

A continuación vemos como tenemos definido una tabla por subtipo:

Ahora vamos a definir los mapeos de la base de datos con nuestras clases.

Para el subtipo Book:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class BooksTpCConfiguration : EntityConfiguration<Book>
{
    public BooksTpCConfiguration()
    {
        this
            .HasKey(b => b.Id)
            .MapSingleType(
                b => new
                {
                    Id = b.Id,
                    Name = b.Name,
                    Price = b.Price,
                    Pages = b.PageNumber,
                    Author = b.Author
                }
            )
            .ToTable("BooksTpC");
    }
}

Ver Más

En el post anterior vimos el tipo de herencia Table per Hierarchy (TPH).

Ahora vamos a ver el tipo de herencia en que el tipo base se guarda en una tabla compartida, es lo que llamamos Table per Type (TPT).

En el ejemplo que estamos siguiendo (intro), nuestra clase base Product se guardará en la tabla ProductsTpT que tiene las propiedades de la propia clase base y luego tendremos una tabla por cada subtipo: ShirtsTpT, BooksTpT y TelevisionsTpT como podemos ver a continuación:

Ahora vamos a definir los mapeos de la base de datos con nuestras clases.

Para la clase base Product:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public class ProductsTpTConfiguration : EntityConfiguration<Product>
{
    public ProductsTpTConfiguration()
    {
        this
            .HasKey(p => p.Id)
            .MapHierarchy(
                p => new
                {
                    ProductId = p.Id,
                    ProductName = p.Name,
                    ProductPrice = p.Price
                }
            )
            .ToTable("ProductsTpT");
    }
}

Ver Más

En mi post anterior hice una introducción a EF4 CodeOnly. A continuación entraremos en detalle con el tipo de herencia de TPH:

En TPH, utilizamos una tabla para guardar todos los datos de la jerarquía y mediante una columna que actúa como discriminador determinamos el tipo concreto de la fila y que columnas debemos leer.

La tabla de la base de datos es la siguiente:

La columna que actúa como discriminador es ProductType y será ‘S’ para el tipo Shirt, ‘T’ para Television y ‘B’ para Book.

Ver Más

Entity Framework 4.0 nos ofrece varias formas de generar nuestro modelo, la primera, y que ya existía en la primera versión del producto, era generar el modelo a partir de la base de datos. Esto nos obligaba a empezar diseñando la base de datos para luego generar nuestras clases, lo cual no es lo deseable.

Una segunda opción es el llamado model-first, en que primero diseñamos nuestras clases del dominio y a partir de plantillas T4 y WF – ya sea las plantillas que trae por defecto o unas creadas por nosotros mismos – nos permite generar el script para crear la base de datos. Esta opción, aun siendo mejor que la anterior no da lugar a mucho juego.

Si realmente lo que queremos es total flexibilidad y no usar ni el diseñador ni pelearnos con el xml del fichero .edmx, podemos obtener la funcionalidad que necesitamos mediante el uso de la librería Microsoft.Data.Entity.CTP y disponible aquí. Como podéis deducir por el nombre aun se encuentra en fase CTP pero ya podemos realizar bastantes cosas interesantes. Para los que hayan trabajado con nHibernate, CodeOnly es la alternativa a *Fluent nHibernate.

Ver Más