2011-09-28 12 views
11

Quiero utilizar dos fuentes de datos diferentes en mi proyecto Azure:EF con Azul - Mezcla de SQL Server y Windows Azure Storage

  • un SQL Server que contiene información parcial básica con respecto a un elemento (permite indexables de datos y búsqueda espacial)
  • un almacenamiento de Windows Azure que contiene información completa con respecto a un elemento restante (recuperado por llave)

De esta manera puedo combinar el potente de SQL Server con la escalabilidad fácil de Windows Azure Storage.

Imagínese esta clase de dominio POCO:

class Person 
{ 
    string Id { get; set; } 
    string Name { get; set; } 
    byte[] Picture { get; set; } 
    string Biography { get; set; } 
} 

me gustaría utilizar Entity Framework con el mapeo de fluidez para permitir EF entender que las propiedades imagen y la biografía deben ser cargados desde Windows Azure Storage (mesa, gota) en lugar de SQL Server (posiblemente Lazy cargado).

¿Hay alguna manera con EF (o NHibernate) para hacer esto o tengo que implementar mi propia estrategia ORM?

Gracias

Respuesta

6

creo que no se puede dejar EF sabe de almacenamiento Azure pero se puede mapear las propiedades necesarias solamente a una tabla específica. Por ejemplo,

modelBuilder.Entity<Person>().Ignore(p => p.Picture); 

Así que asumiendo que tiene una clase repositorio para su clase de persona, lo que quiere se puede lograr fácilmente rellenando la clase repositorio con la API de almacenamiento de Azure y EF.

6

Está tratando de resolver este problema demasiado pronto (en el DAL) en mi opinión. Mire la web, obtiene datos grandes (por ejemplo, imágenes) en una llamada separada al servidor. Eso ha escalado muy bien. Los datos de la imagen no se incluyen en el documento en sí por una razón, simplemente ralentizaría todo y no sería muy tolerante a las fallas. Si los unes en una entidad, obtienes la rápida recuperación de entidades que tu servidor de imágenes desacelera, ya que ambos deben unirse antes de dirigirse hacia la capa de tu empresa y, finalmente, hacia la capa de presentación. Y en la capa de negocios, es probable que estos datos solo estén desperdiciando memoria (es por eso que queremos cargarlo de forma perezosa). Así que creo que estás tomando la decisión demasiado temprano. Lo que usted describe como su objeto de dominio se parece a un objeto de dominio de la capa de presentación, similar a un ViewModel. No soy demasiado aficionado al diseño impulsado por el dominio, pero si bien existe un modelo general de su aplicación, asumo que cada parte de su aplicación requerirá una implementación ligeramente diferente de ese modelo.

En cuanto a la carga diferida, si tiene eso habilitado e intenta enviar su objeto por cable, incluso si Picture no se cargó, se serializará ya que el serializador de contrato de datos (o cualquier otro) llamará a su propiedad.

Probablemente esa no sea la respuesta que quería, pero sentí que tenía que decir esto. Por supuesto, estoy abierto a comentarios y críticas.

Cuestiones relacionadas