In Strandz LGPL subclasses of DataStore can be used to interact with any object-orientated database layer. This means that an application can switch to using a different ORM API relatively easily. As such the Strandz LGPL DataStore achieves the same purpose as the Data Access Object (DAO) design pattern. Using the DataStore approach means that your application code does not need to perform any extra steps - it just grabs the data from a DataStore, alters it, and later does a commit on the same DataStore.

In About Strandz/Example/Basic Theory we saw that core Strandz works with lists of DOs. Most applications need to talk to a database in a transactional manner however, and so non-core Strandz supports a few different types of data sources. The code for these is directly under the package store. The types of DataStore that are currently supported are, by their class names, SerializedFileData, XMLFileData, MemoryDataStore, CayenneDataStore and JDODataStore. By swapping one of these for another it is straightforward to change completely where and how the DOs are persisted. Apart from specifying a different type of connection the only other thing you may have to do is write another set of queries. Your application will then be database agnostic. To illustrate, these are the new classes that needed to be created to make Wombat Rescue work against an in memory database: MemoryWombatConnectionTask, MemoryWombatDataStore and MemoryWombatDomainQueries. Of these the first two are small classes and the third is quite substantial because it contains all the queries. Here is an example:

initQuery( WombatDomainQueryEnum.GROUP_WORKERS,
    new LoopyQuery(
        WombatData.WORKER,
        WombatDomainQueryEnum.GROUP_WORKERS.getDescription())
    {
      public boolean match( Object row)
      {
        boolean result = false;
        Worker worker = (Worker)row;
        if(!worker.isDummy() && !worker.getBelongsToGroup().isDummy())
        {
          result = true;
        }
        return result;
      }
      public int compare( Object one, Object two)
      {
        return workerCf( one, two);
      }
      public void chkResult( Collection c)
      {
        pUtils.chkNoNulls( c, getId());
      }
    } );

If you are moving from transactional to non-transational then the called code does not try to compensate. Thus rollbackTx() will be a 'no-op' if you have moved to a FileData data store, reflecting the fact that the file based data sources don't actually have transactions with rollback segments that need to be rolled back.

If for example you wanted to write a Strandz LGPL application that queried from and updated a Hibernate data store, then you can do this without writing a DataStore subclass. It would simply make it easier to switch to another DataStore later if a HibernateDataStore class was used. The converse of this is also true: non-Strandz LGPL applications are quite free to use Strandz's data store support, which is actually nothing more than a lightweight yet all-encompassing abstract factory layer.

DataStore compliant applications will each have their own sub-package beneath store. This is one place you could look to get an idea of just what DOs are used by an application, what queries are executed and what types of data store are supported. As it is possible for many applications to share the same store sub-package, we have used the term application-domain to describe the data access aspect of an application.

If you take a look at the DOs (incidentally the actual DOs are stored under the package data, not under the package store) for About Strandz/Example/Rostering Application you will see a slightly unusual method signature: isDummy(). This will be reflected in some of the queries that will be collected together under store.wombatrescue.

If DOs don't have any null references where there could be references to other DOs then there will never be any NullPointerExceptions! Hence in the Strandz applications that have been written so far there is always a special DO in the extent of all DOs of a particular type, the dummy, or NULL one. If you need to test whether a reference IS NULL then use isDummy() instead.