A Simple ToDo List: Persisting Data with the Sterling NoSQL Database

by Mike Gold

Introduction

There are some folks out there in the .NET world that have really contributed to some great architectural solutions for the  Window's Phone.  One is  Laurent Bugnion (GalaSoft) who introduced the MVVM-Light framework for the phone.  Another is  Richard Griffen who leads the WP7 Contrib project.  Finally there is a bright guy from Wintellect by the name of Jeremy Likness.  He has developed a NoSql database for the Windows Phone that makes persisting data completely mindless.  The other nice thing about the Sterling Database is that it is LINQ aware, so you can query its contents using LINQ expressions.    In the following article, I will describe for you how you can implement the Sterling database in your phone  project with little to no effort and begin persisting your models.

The DB Setup

The Sterling Database is an object persistence mechanism.  Once you've set up the sterling database in your application,  you can persist your instances at will.   First you'll need to add references to the Sterling engine to your project.  You can download the sterling engine from codeplex to get you started persisting objects on your phone.  The binaries support .NET 4.0, Silverlight 4 and 5 and of course, WP7.  Once you've gotten a hold of the assemblies, you can reference them in your phone solution.

Initialization  is fairly straightforward and the code is shown in listing 1.  First the engine is constructed and activated.   Then a database is registered with the engine.  The engine will be active until its disposed of at the end of the application.

Listing 1 - Setting up the Sterling Database in app.xaml.cs

// Code to execute when the application is launching (eg, from Start)
// This code will not execute when the application is reactivated
private void Application_Launching(object sender, LaunchingEventArgs e)
{
    SetupTheDatabase();
}
    
private void SetupTheDatabase()
{
    // create the sterling engine
    _engine = new SterlingEngine();
    
    // create a logger for the sterling db
    _logger = new SterlingDefaultLogger(SterlingLogLevel.Verbose);
    
    // activate the sterling engine
    _engine.Activate();
    
    // Register your database with the sterling engine and specify its persistence in isolated storage
    Database = _engine.SterlingDatabase.RegisterDatabase<ItemsDatabaseInstance>(new IsolatedStorageDriver());
}

  Listing 2 shows the ItemsDatabaseInstance we needed to create in order to persist our to do ListItems in the database.  The Schema of the database uses the CreaetTableDefinition generic method to specify which classes are registered with the Sterling database. The first generic type parameter in the CreateTableDefinition method is the model type and the second generic type parameter is the key type.  The lambda bindings specify the property that we want our class to key off of. 

Listing 2 - The Database Definition for Sterling

using System;
using System.Collections.Generic;
using ItemList.Model;
using Wintellect.Sterling.Database;
   
namespace ItemList
{
    public class ItemsDatabaseInstance : BaseDatabaseInstance
    {
        public override string Name
        {
            get
            {
                return "ItemsDatabase";
            }
        }
   
        protected override List<ITableDefinition> RegisterTables()
        {
            return new List<ITableDefinition>
   
                        {
                            // we are only registering the To Do list item with the Sterling engine in this example
                            CreateTableDefinition<ListItem, int>(testModel => testModel.Key)
                        };
        }
   
        protected string DATAINDEX
        {
            get { return "dataIndex"; }
        }
    }
   
}

If we look at the ListItem model we created more closely, we can see that we really don't need to concern ourselves with the Sterling database at all when defining the model.  This nice decoupled approach makes using the database to persist our objects very simple.  We simply need to provide a Key property and that's it.  All the Sterling specific code is located in the Database TableDefinition in Listing 2.

Listing 3 - The Model we are Persisting with the Sterling Database

namespace ItemList.Model
{
   
   public class ModelBase
    {
        private int _key = -1;
        public int Key
        {
            get { return _key; }
            set { _key = value; }
        }
    }
   
   
    public class ListItem : ModelBase
    {
        public bool IsFinished { get; set; }
   
   
        public string Text { get; set; }
    }
}

In order to save the to do ListItems,  we created an extension method to ease the task a little.  Listing  4 shows how we can encapsulate the access to the App object inside a Save extension method.  We can also query the database for the last index and use it to give us the next unique key in the database.  (Some people might consider a Guid a better approach here, and you can just as easily do this by making your Key of type Guid).  Since there is no danger in this particular app of pulling non-unique keys because the app removes all of the  to do items when you click the remove buttons, it should always generate a unique integer for all new items added to the list.

Listing 4 - Extension for Saving our ListItem Model

public static class Extensions
    {
        public static void Save(this ListItem listItem)
        {
            int currentIndex = (Application.Current as App).Database.Query<ListItem, int>().Count();
            if (listItem.Key == -1)
            {
                listItem.Key = currentIndex;
            }
             
            (Application.Current as App).Database.Save(listItem);
            (App.Current as App).Database.Flush();
   
        }
     }

Using Sterling in our ViewModel

Using MVVM, we wrap our ListItem in a ListItemViewModel.    The ListItemViewModel propagates the models properties to the View.  In this example, we chose to persist our model any time we make a change to the properties in our ViewModel.  So as soon as any of the setters in our ListItemViewModel are called, we call Save on the property in the model.

Listing 5 - Persisting the Model from the ViewModel when the to do  item has changed

using GalaSoft.MvvmLight;
using ItemList.Extensions;
using ItemList.Model;
  
namespace ItemList.ViewModels
{
    public class ListItemViewModel : ViewModelBase
    {
        public ListItemViewModel()
        {
            _listItem = new ListItem();
        }
  
        private readonly ListItem _listItem;
  
        public ListItemViewModel(ListItem model)
        {
            _listItem = model;
        }
  
        public bool IsFinished
        {
            get { return _listItem.IsFinished; }
            set
            {
                _listItem.IsFinished = value;
                // check state changed, save ListItem model to isolated storage
                _listItem.Save();
                RaisePropertyChanged("IsFinished");
            }
        }
  
  
        public string Text
        {
            get { return _listItem.Text; }
            set
            {
                _listItem.Text = value;
                // text changed, save ListItem model to isolated storage
                _listItem.Save();
                RaisePropertyChanged("Text");
            }
        }
    }
}

We also want to be able persist the model whenever we add a new ToDo ListItem.   We can use a button in our main phone view to bind an ICommand in our main view model and signal that we want to add a new todo list item to our phone screen.  The Command Method inside our main view model for adding a new item and saving it is shown in Listing 6.

Listing 6 - Adding a new ToDo list item to our phone view and saving the item to the phone

private void OnAddToDoCommand(string text)
{
    var model = new ListItem() {IsFinished = false, Text = text};
    model.Save(); // persist it
    var listItemViewModel = new ListItemViewModel(model);
    ListItems.Add(listItemViewModel);
    PromptEntry = false;
}

Conclusion

There is probably a lot more we could have shown you in this example, but this will certainly give you enough to get started with the Sterling engine and persisting simple model objects.  I want to give credit to a few others whose ideas helped me get this application working with MVVM.  One is Max Paulousky who has a cool bindable application bar button for allowing me to bind menu buttons to my viewmodel.  Another shout out goes to Laurent Bugnion (GalaSoft)(Mentioned in the intro)  who created the MVVM-Light library which just makes the MVVM pattern more doable task on the phone. 

You can also follow us on Twitter @winphonegeek

Comments

    public static IEnumerable<ListItem> Load(this IEnumerable<ListItem> listItem)
    {

        var list = (Application.Current as App).Database.Query<ListItem, int>();
        return new ObservableCollection<ListItem>(list.Select(item => item.LazyValue.Value).ToList());
    }