Persistent Cache Repository using SQLite

A while back I blogged about an ICacheRepository. I still really like that concept, although admittedly there a few updates that I should make to the implementation.

The basic implementation that I shared before was for an in memory cache. There are plenty of document databases that I would recommend for you to use as a persistent cache mechanism, and they would also have the added benefit of being distributed across services.

What do you do if you need a persistent cache, but you don't have any of those document databases available? Just use files! By which I mean SQLite.

Would this stand up under load? Probably not.
Would I recommend that production systems use this? No.
Is it super simple to setup? Yes, yes it is!

• GitHub - Source Code, Tests, & Sample
• NuGet Gallery - CacheRepository.SQLite

Enjoy,
Tom

How to use Entity Framework and SQLite

SQLite is the definition of a lightweight database. Using SQLite you can run an entire database with only a 304 KB executable and a database file. It's fast, stable, and very easy to use. Entity Framework is Microsoft's official ORM, and it has support for SQLite!

SQLite Tools

To run SQLite you need only to download the precompiled SQLite binaries for windows:

• SQLite Downloads (Precompiled Binaries for Windows)

You can easily manipulate the database via command line. However, if you would prefer to use a GUI, there is a wonderful Firefox plugin for managing your SQLite databases.

• SQLite Manager (Firefox Addon)

Entity Framework Setup

To get stated using Entity Framework you will need to add two NuGet packages to your solution:

1. EntityFramework
2. System.Data.SQLite (x86/x64)

After that you will need to make sure that your app.config file has properly registered the both a System.Data.SQLite provider and provider factory.

Two Important Questions about PLINQO EF

The .NET community is the best development community ever.
How do I know that? Because they ask the best questions!

Here are two really important questions that we have been asked concerning PLINQO for Entity Framework that I wanted to call some extra attention to:

What is the advantage of using PLINQO EF instead of standard Entity Framework?

In 1.0 the primary goal was to improve the regeneration story of Entity Framework, thus making it easy to update and sync data and code changes. The entities are pretty much equivalent, but the PLINQO query extensions greatly improve and simplify the composition of queries.

With future versions there will be more features brought in from the PLINQO for L2S feature set.  This will include built in caching, auditing, enhanced serialization, possibly WCF and DataServices support, and hopefully batch/future queries!

What are the benefits, if any, of moving to PLINQO EF over PLINQO L2S?

Such benefits are not there yet, but will be. The primary reason to migrate right now would be to inherit the benefits that standard EF has over L2S, most notably is its multiple database support (so more than just SQL Server).

There will be a simple migration path between the two versions of PLINQO, but the bottom line is that PLINQO EF is not ready for that yet. It is still in beta, and is simply not yet as feature complete as PLINQO L2S. It's going to take one or two releases until we get there, but we will get there! :)