EF 与 Azure - 混合 SQL Server 和 Windows Azure 存储答案

【问题标题】：EF with Azure - Mixing SQL Server and Windows Azure StorageEF 与 Azure - 混合 SQL Server 和 Windows Azure 存储
【发布时间】：2011-11-26 16:41:58
【问题描述】：

我想在我的 Azure 项目中使用两个不同的数据源：

一个 SQL Server，其中包含有关项目的部分基本信息（允许可索引数据和空间搜索）
一个 Windows Azure 存储，其中包含关于项目的完整剩余信息（通过密钥检索）

通过这种方式，我可以将强大的 SQL Server 与易于扩展的 Windows Azure 存储相结合。

想象一下这个 Domain POCO 类：

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

我想使用具有流利映射的实体框架让 EF 了解属性 Picture 和 Biography 必须从 Windows Azure 存储（表、blob）而不是 SQL Server（可能是延迟加载）加载)。

EF（或 NHibernate）有办法做到这一点，还是我必须实现自己的 ORM 策略？

谢谢

【问题讨论】：

标签： entity-framework orm azure azure-storage

【解决方案1】：

我认为您不能让 EF 了解 Azure 存储，但您只能将必要的属性映射到特定表。例如，

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

因此，假设您的 Person 类有一个存储库类，您可以通过使用 Azure 存储 API 和 EF 填充存储库类轻松实现您想要的。

【讨论】：

【解决方案2】：

在我看来，你试图过早地解决这个问题（在 DAL 中）。看看网络，它在对服务器的单独调用中获取大数据（例如图片）。这已经很好地扩展了。图片数据不包含在文档本身中是有原因的，它只会减慢一切，而且容错性也不是很好。如果您将它们放在一个实体中，您将获得快速的实体检索，这会被您的图片服务器减慢，因为它们都必须在离开您的业务层并最终进入表示层之前聚集在一起。而在业务层，这些数据可能只是在浪费内存（这就是你想要延迟加载它的原因）。所以我认为你做决定太早了。您描述为域对象的内容在我看来就像表示层的域对象，类似于 ViewModel。我对领域驱动设计不太感兴趣，但是虽然您的应用程序有一个通用模型，但我假设您的应用程序的每个部分都需要对该模型的稍微不同的实现。

关于延迟加载，如果您启用了延迟加载并尝试通过网络发送您的对象，即使图片未加载，它也会被序列化，因为数据协定序列化程序（或任何其他）将在您的属性上调用 get .

这可能不是你想要的答案，但我觉得我不得不这么说。我当然愿意接受 cmets 和批评。

【讨论】：