Anatomy of an ObjectSql provider
The heart of the ObjectSql system is the provider interface which convert objects into persisted streams of information and saves and retrieves them from storage such as disk or a database. A provider can be written for any new database or other storage device and used with the ObjectSql system to persist objects to storage by implementing the required interfaces. Some abstract classes also provide common functionality so that developers of providers can focus on the implementation of their provider specifics.
At this time a Microsoft Sql Server provider and an Xml Provider will be available with the ObjectSql launch. An Oracle and MySql provider will follow shortly.
A provider is made up of 5 seperate classes, each with a different and important function
Context
The context contains all the information to persist an assembly to a certain storage device. For the SqlContext provider, this contains SqlServer details and provides Connection objects. You specify the server, database, and security settings (if required). The XmlProvider contains the directory used to save the xml files to. The context follows the Factory pattern and is responsible for creating the other provider objects.
Finally the Context is responsible for verifying if the assembly is valid for any existing deployments and creating any new storage, such as tables, stored procedures, xml files etc.
The Context class is a MarshalByRef object which means an instance can be accessed from another machine using Remoting.
(abstract class Context, must implement IContext)
Command
The command class is responsible for manipulating persistable objects. It contains standard methods to Update, Insert, Delete and Select an object as well as executing a Query. It requires a valid Context.
The Command object is a MarshalByRef object.
(abstract class Command, must implement ICommand)
Concurrency
The Concurrency class holds information about the state of an object when it was last retrieved from storage. It is used to make sure information is not changed by another user causing a conflict or data inconsistency. Each object must have a valid concurrency object.
Concurrency is serialized across remoting boundaries.
(abstract class Concurrency, must implement IConcurrency)
Formatter
The formatter is responsible for moving values between storage and the persisted object, and updating the concurrency. When a property is another object, it is also responsible for creating that object, if required, or retrieving the correct object if one has already been created.
(abstract class Formatter, must implement IFormatter)
Transaction
The transaction class coordinates updates between 2 or more objects. When objects are assigned a transaction, the updates are only committed to storage once all updates have been successfull. If any update fails, all updates are rolled back in the storage. For the SqlProvider, Transact Sql transactions are used across a common connection. For the XmlProvider, the xml files are locked and saved or discarded.
The Transaction object is a MarshalByRef object.