我使用EF 5和代码开发了一个非常好的网络应用程序。但是在运行基准时,我发现性能并不像我想的那么好......进一步看,我发现EF生成的所有查询都与Select * From
类似,这不是最佳实践。
在这里阅读这个答案Select Specific Columns from Database using EF Code First我明白我可以生成一个视图并将其映射到一个实体。我的问题是如何首先使用EF 5代码将视图映射到实体,反之亦然?
我之所以这样说的原因是:我有一个非常宽的表格,我按名称执行“初步搜索”搜索项目,然后在一个案例中返回其余部分...在另一个案例中我有一个大表和大多数时候我只使用标题和描述而不是LOB列......在所有的情况下我从数据库中得到的东西我没有使用...
因此,如果我确实可以将视图映射到实体,反之亦然,我可以在主干和应用层之间节省很多带宽......
答案 0 :(得分:1)
这与你所说的不一样 - 即不是一个确切的答案 - 但它通过EF称之为“观点”来解决性能问题。
我建议你试试EF Power Tools - 和'生成视图'。
通过运行 - 将'views'文件添加到项目中 - 这是一个.cs
- 并且增强了核心EF性能(这是一个EF功能,而不是代码优先 - 但是我们现在可以使用代码优先的电动工具。
它没有添加'Db视图' - 但据我所知 - 它的工作原理是预分析和代码生成SQL模板。
“在实体框架可以针对概念执行查询之前 模型或保存对数据源的更改,它必须生成一组 本地查询视图以访问数据库。意见是其中的一部分 每个应用程序域缓存的元数据。如果你创建 它们是同一应用程序域中的多个对象上下文实例 将重用缓存元数据中的视图而不是重新生成 他们。因为视图生成是整体的重要组成部分 执行单个查询的成本,实体框架使您能够 预先生成这些视图并将它们包含在已编译的项目中。对于 更多信息,请参阅性能注意事项(实体框架)。“ http://msdn.microsoft.com/en-us/library/bb896240.aspx
我可以'感觉'提升表现。
注意:
它有几个问题 - 您可能会在第一次运行它时遇到一些例外情况:
此外,我认为任何其他尝试用“真实”视图手动“调整”Db的尝试都是徒劳的,因为它没有与ORM紧密集成(你需要多一个 - 以及匹配的调用等) )。
答案 1 :(得分:0)
我实现的方式不是很干净但是:
当然所有这些都包含在种子方法中。
不干净但正在跑步。如果您想“迁移”视图的结构,我认为会遇到一些麻烦。但这种方式几乎就像你得到一个实体一样。当然插入和更新可能很敏感,但这不是我的目的。
如果您尊重命名惯例,即使加载策略可用。