Entity Framework 缓存处理与日志监控

  在Kooboo中使用了Entity Framework作为持久化框架,但由于EF1.0并没有提供完整缓存解决方案,一直以来都在为数据缓存而烦脑,在没有找到合适解决方案的情况下,采取了临时的解决办法:直接缓存实体。但是由于Entity实体都是带状态的,并且都与ObjectContext有间接的反向引用,缓存带状态的实体,会造成对象上下文混乱和连接资源的无法被正确释放。因此缓存的Entity实体,首先必须被分离或者重新定义POCO实体来代替Entity实体作为缓存对象。这样一来,所有的缓存实体的关联关系都会失效,造成使用上的麻烦和整个软件框架存在严重的不足。

  再说说EF的SQL日志问题。在之前的LINQ TO SQL的项目中,有一个可视化的调试器,可以查看查询表达式生成对应的SQL语句,这种可以大大方便开发人员的调试工作。可以在EF1.0中,却一直也找不到类似可用的工具。因此,我的做法是通过SQL Profile来查看EF生成和执行的SQL语句。虽然可行,但还是很不方便。

  现在,EF团队终于推出一套比较完整的缓存和SQL执行日志的解决方案,EFProviderWrappers。他们的做法是在原来的EF Provider之上,再加一层包装,通过这层包装拦截,进行数据缓存和日志监控。这里缓存的数据是数据库查询后返回的原生数据,并不是Entity实体对象,这样就可以避免Entity实体状态对缓存造成的的极端负面影响。并且这样的缓存对上层的数据查询本身是透明,在同一个封闭区间内,缓存数据所依赖的实体类型在被更新后(对应的表有发生CURD操作),缓存并会被自动清空。对于日志的监控,经过这层包装后就可以非常容易得到处理。

EfProviderWrapper

  上面的图虽然是说明对SqlClient有效,但由于这层包装并不涉及具体的SQL操作,因此对不同的数据的Provider应该都是有效。下面通过一个自带的实例简单介绍一下如何使用。

  在下载的EFProviderWrappers解决方案中,EFProviderWrapperToolkit,EFCachingProvider,EFTracingProvider这三个工程是真正干事的,其它的工程都是示例工程。在EFProviderWrapperDemo工程,我们可以找到我们所要的例子。

  第一步:在配置文件中添加如下配置:

<system.data>
<DbProviderFactories>
<add name="EF Caching Data Provider"
invariant
="EFCachingProvider"
description
="Caching Provider Wrapper"
type
="EFCachingProvider.EFCachingProviderFactory, EFCachingProvider,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=def642f226e0e59b
" />
<add name="EF Tracing Data Provider"
invariant
="EFTracingProvider"
description
="Tracing Provider Wrapper"
type
="EFTracingProvider.EFTracingProviderFactory, EFTracingProvider,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=def642f226e0e59b
" />
<add name="EF Generic Provider Wrapper"
invariant
="EFProviderWrapper"
description
="Generic Provider Wrapper"
type
="EFProviderWrapperToolkit.EFProviderWrapperFactory, EFProviderWrapperToolkit,
 Version=1.0.0.0, Culture=neutral, PublicKeyToken=def642f226e0e59b
" />
</DbProviderFactories>
</system.data>

NET技术Entity Framework 缓存处理与日志监控,转载需保留来源!

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。