For areas of common standard functionality, where the project maintenance is likely to change hands, I usually recommend using a well built and well documented framework when building Rich Applications but know how important it is to understand the underlying architecture and design patterns a framework uses so as to have a better understanding of any given system. There are a few ORM (Object Relational Mapping) solutions for AIR emerging on the market now such as FlexORM that have caught my eye, many of them using annotations to map classes to database records but what sort of complexity are those ORM solutions managing?

I have recently been reading Martin Fowler’s excellent book Patterns of Enterprise Application Architecture and saw several things I could bring to my own application development toolkit. So in order to better understand the patterns suggested by Fowler, I decided to test the waters and build a basic custom ORM system that I could use on small bespoke projects such as my own projects, where I would be in control of maintenance. Fowler mentions several patterns including Active Record, Data Mapper, Unit of Work, Lazy Load plus many others devoted to the specifics of relational mapping.

Upon researching the subject, it appears that fundamental to the architecture or your Data Access Layer is the decision of whether to follow Active Record or Data Mapper. Now generally, I am not a huge fan of Active Record for a couple of reasons; firstly, from my experiences with Silverlight and Cake it tends to lead to an oversimplification of the data structure, which often means the data of your application does not represent the problem domain accurately. Since the key to developing a quality app is getting the data structure correct, this will likely affect the optimizability and maintainability of your application in the long run. Secondly Active Record breaks the Principle of Single Responsibility within Object Oriented Programming which brings class bloat as model classes cope with both the Domain based business rules as well as the responsibilities of mapping to the database. So since using Active Record does not feel to me like a best practice, we are left with using Data Mapper to structure the data access layer.

So with a Data Mapper approach chosen, from then on in what are the patterns that are the most important to success on a basic level? How should you structure simple projects where you want an organised data layer but don’t know where to start? Let’s break it down into components:

Controlling what needs to be done: Unit Of Work

The Unit of Work Pattern takes a domain object and flags that domain object for an action by the appropriate Data Mapper without actually doing the action until it’s commit() method is called. This way database calls may be managed using bulk transactions limiting individual transactions. UnitOfWork’s main two functional modes are that of flagging objects that are out out of sync with the DB and committing the queued changes to the database. This has the effect of making fewer database transactions as transactions can be postponed till all the relevant fields are changed and the commit function is run. When you can imagine that the alternative would be to run a transaction every single time a field is changed you can see quickly how this pattern can help speed things up. The Unit of Work has methods for managing new,dirty and deleted objects as you can see here:

Fig. 1.1 Unit if Work UML

Fig. 1.2 Unit of Work Actionscript Class

package com.rudiyardley.dbapp.db
{
	import com.rudiyardley.dbapp.model.DomainObject;
	import com.rudiyardley.dbapp.model.Student;
 
	public class UnitOfWork
	{
 
		private var newObjects:Array;
		private var dirtyObjects:Array;
		private var deletedObjects:Array;
 
		public var identityMap:IIdentityMap;
 
		public function UnitOfWork(s:ForceSingle)
		{
			newObjects = new Array();
			dirtyObjects = new Array();
			deletedObjects = new Array();
		}
 
		public function registerDirty(object:DomainObject):void
		{
			dirtyObjects.push(object);
		}
 
		public function registerClean(object:DomainObject):void
		{
			dirtyObjects.splice(dirtyObjects.indexOf(object),1);
		}
 
		public function registerDeleted(object:DomainObject):void
		{
			deletedObjects.push(object);
		}
 
		//	Object will be placed in the DB with an insert statement
		public function registerNew(object:DomainObject):void
		{
			newObjects.push(object);
			registerClean(object);
		}
 
		public function commit():void
		{
			var mapper:IDataMapper;
			var object:DomainObject;
 
			while(newObjects.length>0)
			{
				object = newObjects.shift();
				mapper = DataSession.current.getMapper(object);
				mapper.create(object);
			}
 
			while(dirtyObjects.length>0)
			{
				object = dirtyObjects.shift();
				mapper = DataSession.current.getMapper(object);
				mapper.update(object);
			}
 
 
			while(deletedObjects.length>0)
			{
				object = deletedObjects.shift();
				mapper = DataSession.current.getMapper(object);
				mapper.deleteItem(object);				
			}
 
		}
	}
}

Reading to and From the Database: DataMapper

How do you interface with the DB so that your persistence logic is separate from your application yet not acting as a transactional mess? A data mapper is responsible for translating between domain objects and the database. Usually you will have one class per domain object. You put in an object in the appropriate accessor method and the DataMapper creates,reads,updates or deletes it. Note the data mapper is usually object specific and every persistent DomainObject should have a corresponding DataMapper. DataMappers should live within the DataSession and can also maintain identity maps there for caching whenever reading from the database.

Fig. 1.3 A typical abstract DataMapper:

The DataMapper above represents the main things you will tend to need from a data mapper. A specific mapper may contain more methods depending on what type of searches it requires. A Domain Object’s corresponding mapper should contain the logic for building all the SQL responsible for it’s persistence in the database. An easy way to prepare and select appropriate mappers is to have some kind of Factory Method on the DataSession object that accepts a Class reference and spits out a mapper. ie.

DataSession.current.getMapper(GalleryImage);	// Would return a GalleryImage mapper.

Fig. 1.4 Source of a typical DataMapper

package com.rudiyardley.dbapp.db
{
	import com.rudiyardley.dbapp.model.DomainObject;
	import com.rudiyardley.dbapp.model.Student;
 
	import flash.data.SQLConnection;
	import flash.data.SQLResult;
	import flash.data.SQLStatement;
 
	import mx.collections.ArrayCollection;
 
	public class StudentMapper implements IDataMapper
	{
		private var stmtInit:SQLStatement;
		private var stmtCreate:SQLStatement;
		private var stmtUpdate:SQLStatement;
		private var stmtDeleteItem:SQLStatement;
		private var stmtReadAll:SQLStatement;
		private var stmtReadById:SQLStatement;
 
		private var map:IIdentityMap;
 
		public function StudentMapper(conn:SQLConnection,map:IIdentityMap)
		{
			this.map = map;
 
			//	Initialize the other queries
			stmtInit = new SQLStatement();
			stmtCreate = new SQLStatement();
			stmtUpdate = new SQLStatement();
			stmtDeleteItem = new SQLStatement();
			stmtReadAll = new SQLStatement();
			stmtReadById = new SQLStatement();
 
			//	apply the connection
			stmtInit.sqlConnection = conn;
			stmtCreate.sqlConnection = conn;
			stmtUpdate.sqlConnection = conn;
			stmtDeleteItem.sqlConnection = conn;
			stmtReadAll.sqlConnection = conn;
			stmtReadById.sqlConnection = conn;
 
			initDB();
 
		}
 
		//	CREATE TABLE
		private function initDB():void
		{
			stmtInit.text = "CREATE TABLE IF NOT EXISTS students ( id TEXT PRIMARY KEY, name TEXT ); ";
			stmtInit.execute();
		}
 
		//	READ ALL
		public function readAll():ArrayCollection
		{
			var result:SQLResult;
			var items:ArrayCollection;
			var i:int;
			var dataObject:Object;
			var currentStudent:Student;
 
			//	Prepare statement
			stmtReadAll.text = "SELECT * FROM students;";
			stmtReadAll.execute();
 
			//	Get results and iterate over result
			result = stmtReadAll.getResult();
			items = new ArrayCollection();
			if(result.data != null)
			{
				for(i=0;i<result.data.length;i++)
				{
					dataObject = result.data[i];
					currentStudent = createCleanDomainObjectFromDataObject(dataObject) as Student;
					DataSession.current.registerObject(currentStudent);
					items.addItem(currentStudent);
				}
			}
			return items;
		}
 
		//	READ BY ID
		public function readById(id:String):DomainObject
		{
			var result:SQLResult;
			var studentToReturn:Student;
			var dataObject:Object;
 
			studentToReturn = map.getObjectByTypeId(Student,id) as Student;
 
			if(studentToReturn != null)
			{
				return studentToReturn;
			}
 
			stmtReadById.text = "SELECT * FROM students WHERE id=:id;";
			stmtReadById.parameters[":id"] = id;
			stmtReadById.execute(1);
 
 
			result = stmtReadById.getResult();
			if(result.data == null)
			{
				return null;
			}
			stmtReadById.cancel();
			dataObject = result.data[0];
			studentToReturn = createCleanDomainObjectFromDataObject(result.data[0]) as Student;
			DataSession.current.registerObject(studentToReturn);
			return studentToReturn;
		}
 
		//	CREATE
		public function create(object:DomainObject):void
		{
			if(readById(object.id)==null)
			{
				stmtCreate.text = "INSERT INTO students (id,name) VALUES (:id,:name);";
				stmtCreate.parameters[":id"] = Student(object).id;
				stmtCreate.parameters[":name"] = Student(object).name;
				stmtCreate.execute();
			}
		}
 
		//	UPDATE
		public function update(object:DomainObject):void
		{
			stmtUpdate.text = "UPDATE students SET name=:name WHERE id=:id; ";
			stmtUpdate.parameters[":id"] = Student(object).id;
			stmtUpdate.parameters[":name"] = Student(object).name;
			stmtUpdate.execute();
		};
 
		//	DELETE
		public function deleteItem(object:DomainObject):void
		{
 
			stmtDeleteItem.text = "DELETE FROM students WHERE id = :id ; ";
			stmtDeleteItem.parameters[":id"] = Student(object).id;
			stmtDeleteItem.execute();
		};
 
		//	Utility function creates a clean domain object
		private function createCleanDomainObjectFromDataObject(dataObject:Object):DomainObject
		{
			var student:Student = new Student(dataObject.id,dataObject.name);
			student.markClean();
			return student;
		}
	}
}
 

Handling ID’s using GUIDS

One of the issues I found in working with the fowler patterns was that when doing basic bulk writes or reads Actionscript APIs don’t allow access to the most recent row ID of a record until the entire transaction has been completed. A strategy I found to solve this problem was to create ID’s external to the database. One way to do this was to incrementally update a purpose created field the database every time a record was added to keep track of the currently written id. A simpler method was to use a GUID generator to accomplish the same ends.

var s:Student = new Student(IdGenerator.instance.getId(),name);

Keeping track of identities: IdentityMap

When you have objects that represent objects within the database it is important to keep track of all the objects out there in memory. To this end we can use a registry associated with the data session.

Downloadable Example

I have put together an example of a data access layer within the context of a simple and rather hastily constructed application that can act as an example of the patterns at work here. The application manages a many to many relationship between Teachers and Students. To use the application you can create Teachers or Students and the application adds them to the lists. Then select both a teacher and student together and you can create a relationship.

You can download the source code here

The other day I was preparing a spec and getting a colleague to double check my correspondence. They brought up that the client likely did not know what Flex was and that I should be prepared to explain it to the client in the meeting we were tabled to have. My first reaction was fine until it dawned upon me that finding the words to describe flex for someone who only really understands flash as a scripting and animation technology may actually be a little difficult so thought I would share with you what I came up with as well as ask for opinions on the matter.

Here are a few possible answers:

1. Flex is a collection of compilers that output SWF bitecode
2. Flex is a framework that is based on MXML as a meta-language for forming SWF bytecode
3. The Flex framework uses both MXML and a bunch of custom Actionscript classes to define the various visual and non-visual elements of Rich Applications
4. Flex makes building Rich applications with Flash faster by leveraging the use of standard user interface components and layout method

Any other thoughts?