One of the things I've done quite frequently over the years to improve performance against databases is to cache items which I consider relatively static. When I was writing the DataLayer wrapper I wanted to incorporate this in a very quick and easy way to ensure people could actually use this without the amount of hassle normally involved in setting up caching.
With Entity Framework, you'll often use the lazy-loading without thinking that you're actually lazy-loading any items due to the easy relations defined by the generated classes, or the code-first classes, I wanted an easy way to sort out easy caching options for these as well, but the problem here is that the model shouldn't really have access to data-retrieval options in a standard tiered setup, so I've added some reflecting magic that gets the job done.
The Quick Cache classes, (Qc and Qsc, for Quick-Cache and Quick-Single-Cache respectively) are accessible in the Mijan.Core.DataLayer. What they do is look up an implementation of IDbCache and uses this implementation to access the database - if you've already defined a DalCache class like mentioned in the previous post, it's already done! You can start using Qc and Qsc as much as you want for all your caching needs!
A practical example of this would be in a blog-model, where you rarely add authors, or any model with enum/type foreign keys, consider the following Code-First example in a Blog entity class.
Here you can simply use blog.AuthorCached to access a cached variant, where the blog.Author would actually load the row from the database.
What happens behind the scenes here is that the Quick Cache will load the entire Author table, and maintain it in-memory. The Qc class will return the List of those objects, while the Qsc will return a single entry there through a Dictionary approach, making it a lot more efficient for single-entry lookups. A note here is that Qsc will not work unless there's a single Primary Key on the table, due to the need for the initial reflection and dictionary approach becoming excessively complex with composite keys and potentially needing tuples to maintain key values. Simply use Qc instead for these scenarios.
Example of how to use Qc as follows, in this case, we want to cache all the posts for a given blog, as accessed through the code-first entity.
It's important to note that by default everything grabbed through this approach will be detached from its context, if you for some reason need the context attached, there is a GetWithContext for that as well, but I'd strongly recommend that you really know what you're doing in that case, and that you know how to handle potential errors coming from objects attached to "different contexts".
If you need to refresh data for whatever reason, Qc.Clear<T>(); and Qsc.Clear<T>(); will do the trick. Also, due to the nature of reflection and potential errors, there will be an exception thrown if you try to use this and there's anything but *one* instance of IDbcContext defined.