实体框架 4 + Silverlight 持久实体图
我们目前正在使用 Silverlight 4（使用 PRISM）和 Entity Framework 4 构建我们的第一个大型应用程序。现在我有一个关于持久视图模型数据的一般问题。 假设我有域对象，这些对象可转换为具有多个关联的 EF4 实体（具有集合的实体、再次具有集合的实体等）。在用户操作期间/之后保留这些图表的最佳方法是什么？编写更细粒度的存储库方法（例如“AddEntityToParent”和“RemoveEntityFromParent”）会更好，还是只从视图中获取所有数据并将其推送到“SaveLargeParentEntity”方法？ 我是否可以在 Silverlight 中“缓存”子对象的视图模型项目并稍后将其全部推送到 EF4，或者我是否必须对用户界面中更改的每个项目进行精细更新？有什么好的建议吗？我希望我的问题足够清楚。谢谢。
we are currently building our first large application with Silverlight 4 (using PRISM) and Entity Framework 4. Now I'm having a general question about persisting view model data.
Suppose I have domain objects which translate to EF4 entities with multiple associations (Entity having collections, having collections again etc..). What would be the best way to persist those graphs during / after user actions? Would it be better to write more granular repository methods like "AddEntityToParent" and "RemoveEntityFromParent" or just take all the data from the view and push it to a "SaveLargeParentEntity" Method?
Can I "cache" the view model items for child objects in Silverlight and push it all down to EF4 later or would I have to make a granular update for every single item changed in the user interface? Any good advise? I hope my question was clear enough. Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您实际上是在基本 CRUD 操作和使用对象图之间做出选择。我会选择第二种方法，因为 CRUD 操作通过 Web 服务发送的对象图可能非常繁琐。
当使用通过 Web 服务发送的对象图时，您必须处理分离的行为。分离的实体+对象图会带来一些麻烦 更新关系时。最好的方法通常是在更新之前加载整个图表（获取附加实体）并将接收到的图表合并到附加图表中 - 它将为您正确跟踪更改。
但由于您使用的是有状态的 Silverlight，您还可以考虑使用自我跟踪实体 (STE)。 STE 能够在与 EF ObjectContext 分离后跟踪更改。因此，您可以将由 STE 组成的对象图从 Web 服务返回到 Silverlight 应用程序，对 STE 进行一些更改并将相同的对象图发送回 Web 服务。 应用更改 将为您处理大量工作。请注意，对于以下服务，STE 并不是最佳解决方案应该暴露给一般的 Web 应用程序或非 .NET 客户端。
You are actually making a choice between basic CRUD operations and working with object graphs. I would choose second approach because CRUD operations over web service can be very chatty.
When working with object graphs send over web service you have to deal with detached behavior. Detached entities + object graph couses some troubles when updating relations. The best approach usually is to load the whole graph before update (get attached entities) and merge received graph into attached one - it will correctly track changes for you.
But because you are using Silverlight which is stateful you can also think about using Self tracking entities (STE). STEs are able to track changes after they are detached from EF ObjectContext. So you can return object graph consisted of STEs from web service to Silverlight application, make some changes to STEs and send same object graph back to web service. Applying changes from STEs will handle a lot of work for you. Be aware that STEs are not the best solution for services which should be exposed to general web applications or non .NET clients.