Entity Framework is a popular object-relational mapping framework for .NET by Microsoft. It enables you to work with relational data through domain objects. And, it eliminates the need for most of the database persistence code that you would otherwise need to write.
Entity Framework’s popularity has resulted in it being used frequently in high transaction applications where performance and scalability are critical. But, in most high transaction cases the database quickly becomes a bottleneck. This is because unlike the application tier where you can add more application servers as you need to scale, you cannot do the same with the database tier.
The only way to achieve this scalability is with and in-memory distributed cache like NCache. NCache is an extremely fast and scalable in-memory distributed cache for .NET applications. It lets you cache application data, reduce those expensive database trips, and improve your application performance and scalability.
Although Entity Framework does not provide a Second Level (L2) Cache provider model, NCache has implemented a custom ADO.NET provider for Entity Framework with which NCache can plug-in and cache results of Entity Framework queries. This allows you to start using in-memory distributed cache in your Entity Framework application without making any code changes.
If your Entity Framework application is running in a multi-server environment then you need a distributed cache as an Entity Framework Second Level Cache. And, NCache is an ideal Entity Framework Second Level Cache for multi-server configurations and you should use it for these reasons:
The best thing about using NCache with Entity Framework is that there is no programming required on your part. You simply modify your application’s configuration files and specify NCache as your Second Level Cache provider. Here is an example of app.config changes:
<connectionStrings> <add name="NorthwindEntities" connectionString="metadata=res:///EF.csdl|res:///EF.ssdl|res:///EF.msl; provider=Alachisoft.Integrations.EntityFramework.CachingProvider; provider connection string="wrappedProvider=System.Data.SqlClient; Data Source=QCTEST2;Initial Catalog=Northwind;Integrated Security=True; MultipleActiveResultSets=True"" providerName="System.Data.EntityClient"/> </connectionStrings>
Since NCache Entity Framework Second Level Cache provider plugs in as a custom ADO.NET provider, it allows you to run it in analysis mode where it logs all the different queries your application is issuing to Entity Framework. These queries are logged in a file along with a count of how many times this query was called during this analysis mode. Below is an example:
<analysis-report> <!--Call-count = 21--> <query query-text="" ["SELECT FROM Products"] | [stored-procedure-name = ""] caching = "true" expiration-type="absolute" | sliding = "" expiration-time="180" dbsyncdependency = "true"/> </analysis-report>
This allows you to determine which queries you want to cache and for how long. You can also specify database synchronization for some or all of your queries.
By plugging in NCache Entity Framework Second Level Cache provider through app.config changes, you are going to gain an enterprise level distributed cache for your application. Here are some features NCache provides for Entity Framework apps.
Although, using NCache as Entity Framework Second Level Cache is very quick and easy, it only provides you a limited set of NCache features. The reason for this is that NCache is bound by the fact that it is plugged in as a custom ADO.NET provider and must deal at SQL query level. There are numerous NCache features that you are unable to use if you decide to use NCache as Entity Framework Second Level Cache Provider.
The alternative for you is to use NCache directly from within your Entity Framework application by making NCache API calls like all other non-Entity Framework .NET applications do. Although, there is a small programming effort to take this path, you might decide that the benefits outweigh the extra programming effort.
Below is a list of features you would miss if you used it as Entity Framework Second Level Cache versus if you used NCache directly from your application.