EF с Azure - Смешивание SQL Server и Windows Azure Storage

Я хочу использовать два разных источника данных в проекте Azure:

a SQL Server, содержащий базовую частичную информацию относительно элемента (позволяет индексируемые данные и пространственный поиск)
a хранилище Windows Azure, содержащее полную оставшуюся информацию относительно элемента (извлеченного ключом)

Таким образом, я могу объединить мощный SQL Server с простой масштабируемостью Windows Azure Storage.

Представьте себе этот класс POCO домена:

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

Я хотел бы использовать Entity Framework с плавным отображением, чтобы позволить EF понять, что свойства Картинка и биография должны быть загружены из Windows Azure Storage (таблица, blob) вместо SQL Server (возможно, Lazy загружен).

Есть ли способ с EF (или NHibernate) сделать это, или я должен реализовать свою собственную стратегию ORM?

Спасибо

Ответ 1

Я не думаю, что вы можете сообщить EF о хранилище Azure, но вы можете сопоставить только необходимые свойства для конкретной таблицы. Например,

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

Предполагая, что у вас есть класс репозитория для вашего класса Person, вы можете легко достичь, заполнив класс репозитория API-интерфейсом Azure и EF.

Ответ 2

Вы пытаетесь решить эту проблему слишком рано (на DAL), на мой взгляд. Посмотрите в Интернете, он извлекает большие данные (например, изображения) при отдельном вызове на сервер. Это очень хорошо. Данные о снимке не включены в сам документ по какой-либо причине, он просто замедлит все, и он не будет очень терпимым к ошибкам. Если вы объединяете их в одну структуру, вы получаете быстрый поиск объектов, который замедляется вашим файловым сервером, поскольку они оба должны собраться вместе, прежде чем уйти к вашему бизнес-слою и, наконец, к уровню представления. И в бизнес-слое эти данные, вероятно, просто теряют память (вот почему вы хотите ленить ее загрузить). Поэтому я думаю, что вы принимаете решение слишком рано. То, что вы описываете как объект домена, выглядит как объект домена слоя представления для меня, подобно ViewModel. Я не слишком велик в разработке, ориентированном на домен, но, хотя есть общая модель вашего приложения, я предполагаю, что для каждой части вашего приложения потребуется немного другая реализация этой модели.

Что касается ленивой загрузки, если у вас есть это, и вы пытаетесь отправить свой объект по кабелю, даже если изображение не было загружено, оно будет сериализовано, поскольку сериализатор данных (или любой другой) вызовет вызов вашей собственности.

Вероятно, это не тот ответ, который вы хотели, но я чувствовал, что должен сказать это. Конечно, я открыт для комментариев и критики.