In this second version, we use the Data Access Object pattern to improve the overall architecture of our application. A Data Access Object typically encapsulates the data access logic for one entity (in this case: Contact).

An interface (named IContactDAO) defines the “contract”:

package
{
	import flash.utils.ByteArray;
	import mx.collections.ArrayCollection;

	public interface IContactDAO
	{
		function findAll():ArrayCollection;

		function insert(contact:Object):void;

		function update(contact:Object):void;

		function updatePicture(contactId:int, jpeg:ByteArray):void;

		function deleteItem(contact:Object):void;
	}
}

The ContactDAO class implements that interface and provides one specific implementation of the contract (persisting data to the embedded SQLite database).

Benefits:

• The View doesn’t know anything about your data access logic: You can reuse the same view (ContactForm) with a different way to access your data. You would just create another class implementing IContactDAO and pass an instance of that class to ContactForm. Notice that the dao property of ContactForm is of the IContactDAO data type (the interface). This allows us to pass an instance of any class implementing the IContactDAO interface to ContactForm.
• The DAO doesn’t know anything about the view: You can reuse the same data access logic from within different views.

Install inSync Local DAO Edition:

Click here to download the source code. You can also right-click the app and select View Source to view the source code and download the application.

Limitation:

There is still a lot of SQL code to write. There are a few options to overcome that limitation:

• You could create a mini DAO framework where a base DAO class would take care of all the boilerplate code to set up and execute SQL statements. (See the BaseDAO class in Salesbuilder for an example).
• You could use an ORM framework where SQL statements are automatically generated.

In part 3, we’ll look at a version of inSync built with an annotation-based ORM framework.

The list of approaches included:

1. “SQL in View”
2. Data Access Object (DAO) pattern
3. Using an Object Relational Mapping (ORM) framework

I demonstrated a version of inSync (a simple contact management application) built with each of these approaches. I’m dedicating one blog post to each approach. This first post is focused on the “SQL in View” approach. To spice things up just a little bit, inSync also demosntrates how to take a picture of a contact using your webcam and store it in the SQLite database as a blob.

Install inSync Local SQL Edition:

NOTE: this application uses the same skin and overall context as a sample I posted previously to illustrate offline data synchronization using LCDS, but the implementation is entirely different: No LCDS here… just local data access.

Click here to download the source code. You can also right-click the app and select View Source to view the source code and download the application.

Using the “SQL in View” approach, you embed SQL statements as needed in View components. In this example the ContactForm component has create, update, and delete methods with the appropriate embedded SQL statements to insert, update, and delete a contact in the database. This approach works for quick prototyping, but is generally a bad practice. When you mix view logic and data access logic in the same component, neither the view logic, nor the data access logic is reusable: you can’t reuse the view with a different way to access your data, and you can’t reuse your data access logic with a different view.

I provide this approach here as a quick way to get acquainted with the database access API in AIR. For real life implementations, a more partitioned approach such as the DAO pattern or an ORM framework is of course highly recommended. Stay tuned for an example of approaches 2 and 3.

Here are the links:

• Lab instructions PDF (Powering Flex Applications with BlazeDS and Data Services)
• Lab files (including final solutions)

If you didn’t have a chance to attend, you should be able to use this as a BlazeDS/LCDS tutorial as well.

It was great to see all of you at MAX. I hope to see you next year in Los Angeles.

Christophe

I updated my Salesbuilder sample application to leverage the AIR 1.5 capabilities. Salesbuilder 1.5 leverages the new database encryption feature to allow you to secure your local database.

The first time you start Salesbuilder, the application will generate the encrypted database on your local file system. Salesbuilder implements the key generation approach described in the section Using encryption with SQL databases in the manual Developing Adobe AIR Applications. The encryption key is based on a password provided by you and a SALT generated by the system.

You can install the new version and download the source code here.

A basic script explaining how to use the application is available here.

Introduction to BlazeDS and LiveCycle Data Services ES
Moscone West 2007
5:00pm to 6:00pm