An Slight Detour From TDD in Favour of Entity Framework 7

Now that I've created a class for my locations, I need a way to store them. Unfortunately Microsoft, for reasons I have yet to fathom, decided that the best way to store data for MS Store applications would be as XML or JSON text files.

Looking at my fledgling project I can already see that there's a good chance that I'll need objects that will contain other objects, all of which need to be referenced to each other - in short, a classic database scenario. And while other platforms have embraced the lovely lightweight database framework that is SQLite... Microsoft hasn't. Quite.

Looking at Nuget I can see more SQLite .NET wrappers than I can shake a stick at, which makes it very hard to decide which one to go with that will be around for the long term. However, there's another possibility. Remember that I said 'Quite' at the end of the previous paragraph? That's because Microsoft is going to offer SQLite support as part of Entity Framework 7 - but that is currently only available as a pre-release. Still, it seems like the best bet for now, and since I'm curious about it anyway, I'll take that route.

To get started, I'll be perusing the (sparse) EF7 documentation at ef.readthedocs.org/en/latest/index.html, but I'll do a quick recap here, for your enjoyment. I'm working with an Universal Windows project, so I

• Add the following application specific runtime directive to my Default.rd.xml file (found under the project properties): <Type Name="System.Collections.ArrayList" Dynamic="Required All" />. The documentation says that this will become unnecessary at a later point, but for now, in it goes.
• Install the NuGet packages for EntityFramework.SQLite and EntityFramework.Commands. both are pre-release, so make sure you use the -pre option or tick the box that allows you to search pre-release packages.

With the preliminaries out of the way I use EF7 to create my database context class:

	public class QuesterContext : DbContext
	{
	public DbSet<Location> Locations { get; set; }
	protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
	{
	optionsBuilder.UseSqlite(@"Filename=Quester.db");
	}
	}

view raw WorldContext hosted with ❤ by GitHub

I build my solution and use migrations to create my database by running Add-Migration LocationMigration in the package manager console to create my initial database. This actually required a bit of guesswork because my Location class is in a class library rather than my main app project, but after adding a reference to the library to my main app, the command worked fine.

Now, I can't see much to test in my  class itself, but I do want to test that I can do at least basic CRUD operations with my new data context. I don't think those tests can be classified as unit tests, but hey, they're going to be useful, so I'm gonna add them and worry about the semantics another time.

Coming up: Testing CRUD operations CodeProject