|
|
在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操作），緩存并會被自動清空。對于日志的監控，經過這層包裝后就可以非常容易得到處理。
上面的圖雖然是說明對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 緩存處理與日志監控，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
