Mijan.Core - Service Overview

One of the more "common" tasks in computing in general is to have some sort of service running in the background doing all kinds of different things, and as a developer, I feel it's quite nice to just have a very basic framework I can plug into whenever I need something run as a service.

In Mijan.Core I have a Service namespace which contains the basics for your own windows service, complete with installer and the potential to debug as well. This is a very simplistic concept which enables people to make complex services and just quickly plug it into a windows service.

I've defined IService as the base interface for any service, a service needs to be able to start, stop and have a name for identification purposes. The Start method also takes an IServiceHandler as a parameter, if the service for some reason needs to interact with other services running in the same application, in general this parameter can be ignored though.

For the basic executable service, all you have to do is create a console application (not a service!) and have the following in the main entry point.

You can also add another optional parameter after args to specify the name of the service as it would appear in services, otherwise it'll default to MijanService.

I've made a basic TimerService implementation that resides in Mijan.Core.Service, this performs a given task every X minutes during a specified time interval, or simply every X minutes all the time. For a very simple implementation of this, look at the following.

This is essentially all that's needed for a service to execute something every minute, in this instance TimerTick() will write the current time to the Console.

For the service to pick up on this, however, it needs to be plugged in to the app.configuration file. MijanService needs its own little configurationSection, and that's handled as such.

The HelloService line is the timer just implemented above, with its name and namespace as well as the assembly where it's located. The second example is how to specify custom values in the configuration xml. In this case I've added a few properties in another service, and need to add a separate class for the XmlConfiguration, as well as a Service to handle this. As long as I have a service constructor with an XmlElement as its parameter, it will pass its service element into the constructor to handle. For this example, the classes look like

It's important to note the [XmlRoot("service")] attribute, as that's the XmlElement being passed into the constructor.

The service executable takes 3 different parameters when you launch it, either install, uninstall or debug. If you use install, it will be added to the computer's list of services, and will function as any other service in terms of start/stop/recovery. Uninstall obviously uninstalls it, while debug will launch the service in the console window, so you can essentially have it running in a controlled environment before throwing it into fully automated service-mode.

The result and output from running this service in debug mode will be ...

Both services specified in the configuration get to run in their own threads and have their fun!

Mijan.Core.DataLayer - Quick Cache Samples

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.

Mijan.Core.DataLayer NuGet Package - Overview

I've worked on a fair few projects lately, and I always use my own little custom wrapper of the Entity Framework for these projects. It abstracts the storage of the context away by defaulting to have it as a per-httpcontext storage, or a per-thread storage in case of non-web projects.

Other people have expressed interest in using the same approach, and as I'm constantly refining and upgrading what I'm using I've decided to take the step and actually create a NuGet package for this little tool.

This is the initial overview of the DataLayer package, and how to quickly get started using it.

The DataLayer package is named Mijan.Core.DataLayer, and can be installed through the NuGet Package Manager, or console by doing Install-Package Mijan.Core.DataLayer

There's technically support for both the legacy ObjectContext and the new DbContext, but I'm primarily focusing on developing the DbContext part as that's the "surviving" way forward.

Quickstart on how to get up and running with this wrapper is to go about creating your DbContext either through Code First or Db/Model first, then wrap the generated context with your own class-name as an example here.

There are other variants which offer non-static options, but this is the quickest and easiest way to manage your data. Once this is done, you can easily retrieve and manipulate data through the Dal classes you've "created".

In addition to this, the DalCache provides built-in MemoryCache wrapping.

This is just a very quick introduction to what the primary features are in the DataLayer NuGet package. Feel free to comment, I'll most likely add some more information about this package and the Mijan.Core package soon.