EF con Azure - miscelazione di SQL Server e Windows Azure

Question

voglio usare due diverse fonti di dati nel mio progetto Azure:

• un SQL Server che contiene informazioni di base parziale in vista di un oggetto (permette di dati indicizzabili e di ricerca spaziale)
• un archiviazione Windows Azure che contiene completa info per quanto riguarda un elemento restante (recuperato da chiave)

In questo modo posso combinare il potente di SQL Server con la facile scalabilità di Windows Azure Storage.

Immaginate questa classe di dominio POCO:

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

Vorrei utilizzare Entity Framework con la mappatura fluente di lasciare EF capire che le proprietà Picture e la biografia devono essere caricati da Windows Azure (tavolo, blob) anziché SQL Server (probabilmente Lazy caricato).

c'è un modo con EF (o NHibernate) per fare questo o devo realizzare il mio propria strategia ORM?

Grazie

Answer 1

non credo si può lasciare che EF conoscere archiviazione Azure, ma si può mappare le proprietà solo necessarie per una tabella specifica. Ad esempio,

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

Quindi, supponendo che si dispone di una classe repository per la classe persona, ciò che si vuole può essere raggiunto facilmente riempiendo la classe repository con storage API Azure e EF.

Answer 2

si sta cercando di risolvere questo problema troppo presto (al DAL) a mio parere. Guarda il web, recupera grandi dati (ad esempio immagini) in una chiamata separata al server. Questo è andato molto bene. I dati dell'immagine non sono inclusi nel documento stesso per un motivo, rallenterebbe tutto e non sarebbe molto tollerante ai guasti. Se li metti insieme in un unico soggetto che hai il recupero entità veloce che viene rallentato dal server immagine in quanto entrambi hanno a venire insieme prima di partire verso il vostro livello di business e, infine, verso il livello di presentazione. E nel livello aziendale questi dati probabilmente stanno solo sprecando memoria (è per questo che vuoi caricarli pigro). Quindi penso che tu stia prendendo la decisione troppo presto. Quello che descrivi come oggetto di dominio è simile a un oggetto di dominio del livello di presentazione, simile a un ViewModel. Io non sono troppo grandi nel design del dominio driven, ma mentre v'è un modello generale della vostra applicazione, suppongo che ogni parte della vostra applicazione richiederà un po 'diversa attuazione di tale modello.

Per quanto riguarda il caricamento lazy, se è abilitato e si tenta di inviare il proprio oggetto sul cavo, anche se Picture non è stato caricato, verrà serializzato poiché il serializzatore del contratto dati (o qualsiasi altro) chiamerà get sul proprietà.

che probabilmente non è la risposta che volevi, ma sentivo che dovevo dire questo. Ovviamente sono aperto a commenti e critiche.