11
votes

I want to use two different data sources in my Azure project:

  • a SQL Server that contains basic partial info regarding an item (allows indexable data and spatial search)
  • a Windows Azure Storage that contains full remaining info regarding an item (retrieved by key)

In this way I can combine the powerful of SQL Server with the easy scalability of Windows Azure Storage.

Imagine this Domain POCO class:

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

I would like to use Entity Framework with fluent mapping to let EF understand that the properties Picture and Biography must be loaded from Windows Azure Storage (table, blob) instead of SQL Server (possibly Lazy loaded).

There's a way with EF (or NHibernate) to do this or I have to implement my own ORM strategy?

Thanks

2

2 Answers

6
votes

I don't think you can let EF know about Azure storage but you can map only necessary properties to a specific table. For example,

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

So assuming that you have a repository class for your Person class, what you want can be easily achieved by filling the repository class with Azure storage API and EF.

6
votes

You're trying to solve this problem too early (at the DAL) in my opinion. Look at the web, it fetches large data (e.g. pictures) in a separate call to the server. That has scaled very well. The picture data is not included in the document itself for a reason, it would just slow everything down and it would not be very fault tolerant. If you put them together in one entity you've got the fast entity retrieval that is slowed down by your picture server as they both have to come together before leaving towards your business layer and finally towards the presentation layer. And in the business layer this data is probably just wasting memory (that's why you want to lazy load it). So I think you're making the decision too early. What you describe as your domain object looks like a domain object of the presentation layer to me, similar to a ViewModel. I'm not too big into domain driven design, but while there is a general model of your application, I assume that each part of your application will require a slightly different implementation of that model.

Regarding lazy loading, if you have that enabled and you attempt to send your object over the wire, even if Picture was not loaded, it will get serialized since the data contract serializer (or any other) will call get on your property.

That's probably not the answer you wanted, but I felt that I had to say this. Of course I am open to comments and criticism.