Obiwan is being created with the objective of creating an object persistence framework for Delphi applications. With "object persistence" in place an application developer is able to save objects directly to persistent storage (whether this is an RDBMS or a "flat file"), without having to convert the object's data to some other format first.

What design objectives is the framework based on?

To allow different data store implementations to be "plugged in" without requiring any changes to application code. By defining a set of Delphi interfaces and classes as the API we allow different "service providers" to implement the Obiwan specification according to their specific needs.

To provide a small and straight forward standard API that application and component developers can code against. If Obiwan becomes a success it will be possible over time to build a third party component market on top of the standard.

To make persistence as "transparent" as possible within the limits of the Delphi language. One goal is to accomplish "persistence by reachability" (an object is made persistent when it's reachable from another persistent object). Another goal is to allow "just-in-time loading" of objects.

Obiwan is developed with Delphi 6 as the target environment. This should also make it compatible with "near" Delphi releases as well as Kylix. It is also likely that a "mirror" project will target the upcoming Delphi for .Net environment.

What are some of the consequences of these design objectives?

Application developers can focus on implementing the requirements of their applications, rather than on how get data to/from the database.

Problem Domain (Business Model) developers can use standard Delphi classes and interfaces to implement the business rules of the application. When developing "business objects" there will still be work to be done to make classes "persistence capable". With improved metadata (e.g. RTTI) in future Delphi versions (such as Delphi for .Net) these needs will be reduced.

The framework is heavily dependent on Delphi interfaces. It might still be possible for application developers to avoid interfaces in their code, though, if wanted.

Persistence capable classes will have some (memory/performance) overhead to allow proper management of persistent instances. Some classes may not be good candidates for Obiwan persistence (e.g. situations where a large number of "fine grained" objects need to be instantiated at the same time). In most cases the advantages of the Obiwan framework will outweigh this possible overhead.