EF 与 Azure - 混合 SQL Server 和 Windows Azure 存储
我想在我的 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 了解属性图片和传记必须从 Windows Azure 存储（表、blob）加载，而不是从 SQL Server（可能是延迟加载）。
EF（或 NHibernate）有办法做到这一点，还是我必须实施我自己的 ORM 策略？
谢谢
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为您不能让 EF 了解 Azure 存储，但您可以仅将必要的属性映射到特定表。例如，
假设您有一个用于 Person 类的存储库类，则可以通过使用 Azure 存储 API 和 EF 填充存储库类来轻松实现您想要的。
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,
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.
我认为你太早地试图解决这个问题（在 DAL）。看看网络，它在对服务器的单独调用中获取大量数据（例如图片）。这已经扩展得很好。图片数据不包含在文档本身中是有原因的，它只会减慢一切速度，而且容错能力也不是很好。如果将它们放在一个实体中，您将获得快速的实体检索，但图片服务器会减慢实体检索的速度，因为它们必须在离开业务层并最终进入表示层之前聚集在一起。在业务层中，这些数据可能只是浪费内存（这就是您想要延迟加载它的原因）。所以我认为你做出的决定太早了。您所描述的域对象对我来说看起来像是表示层的域对象，类似于 ViewModel。我不太热衷于领域驱动设计，但是虽然您的应用程序有一个通用模型，但我假设您的应用程序的每个部分都需要该模型的稍微不同的实现。
关于延迟加载，如果您启用了该功能并且尝试通过线路发送对象，即使未加载图片，它也会被序列化，因为数据协定序列化程序（或任何其他）将在您的属性上调用 get 。
这可能不是你想要的答案，但我觉得我必须这么说。当然，我愿意接受评论和批评。
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.