TPersistent.com

I have been working towards this for a long time now.  Initially I was undecided what license to use, then it was a matter of wanting to complete some code improvements.  Finally I just decided it was never going to be perfect, especially since I don’t have that much time to work on it at present, so I finally kicked it out of the door.

The framework certainly works.   I have numerous applications and success stories that testify to that.  It does however have some holes.  The biggest of which is Unit Test coverage.  I started writing the framework long before Agile methodology became the rage, and although I see the value of writing tests first, it’s a little harder to write them afterwards.  It’s also very challenging to write tests for GUI elements.

I am also in the process of changing the way the framework deals with Object IDs aka primary keys.  Initially I used an Attribute property to specify if a column was involved in the primary key (apPrimaryKey).  I later introduced the concept of a ThcOID class to encapsulate primary key handling in order to better facilitate keys consisting of multiple attributes, natural keys, and keys made up of non-integer data types.  Currently you have to use both methods for the framework to function correctly since the conversion to ThcOID is not complete.

The design-time aspects of the framework have also undergone an evolution and are no longer complete.  I used to only support Attribute/UI Control Name/UI Control Property Name elements in the UIObjectBinder and used RTTI to set and get the values from the UI Control.  Then I introduced the MGM pattern, providing a much more flexible framework capable of supporting almost any non data-aware control.  If you use a ThcMediator descendant with the ObjectBinder, you must establish the bindings in code.  The same applies to design-time functionality for the DevXGrid.  All column bindings for a view must be created in code.  I typically use a previously written method as a template for a new one.  At some point I would like to have design-time support implemented, or at the very least have some sort of wizard to generate the code.

The project is hosted on SourceForge at http://sourceforge.net/projects/larryhengensopf/.  If you have any issues with the framework, pop me an email.

What is an OPF?

An object persistence framework is essentially a library of pre-written code that takes care of the details of persisting, or permanently storing an object. The object may be persisted to a text file, XML file etc., but in the business world it will most likely be to an RDBMS and for this reason they are sometimes referred to as an ORM (Object Relational Mapper).  Object databases have been around for some time, but they are not used as prominently as RDBMS products so programmers still have to be able to write their objects into a RDBMS, and the easiest way to do that is create an Object Persistence Framework, or layer, that can perform all the CRUD (Create, Read, Update and Delete) operations developers normally have to code by hand.  This enables developers to focus on implementing better UIs, and addressing the problems the application is meant to solve.

The concept of an OPF is nothing new.  Java has TopLink, Hibernate, etc, .NET has a partial port of Hibernate called oddly enough, NHibernate, CSLA, Castle Record and numerous other implementations.  One of the major impediments to an OPF for Delphi is the lack of complete RTTI aka Reflection, and the development environment itself.  Delphi’s IDE is geared to creating RAD applications using it’s component technology.  While this means you can create Object Oriented applications quickly, the benefits of OOP are for the most part lost, because the data is not being manipulated in an object oriented fashion.  As a result code becomes harder to maintain and understand because data validation code is scattered throughout form and data modules.  The use of events on TDataSets can create a spider web of event sequences that produce obscure bugs that are difficult to trace, and more database activity is usually required in a typical RAD application than a truly object oriented one.

How it All Began

My interest in OPFs began when working for a company that developed their own OPF as the foundation for a suite of hospital medical applications written in Delphi 3.  That company went bankrupt, but the validity of their vision of a using an OPF as a foundation for applications was proven to me every time I wrote a database application afterwards.  The more complicated the application, or the more closely it modeled the real world, the more sense it made to use an OPF and write a fully object oriented application.  Eventually, I started working on my own OPF, ensuring that I didn’t make the same design mistakes that were made in the other framework which was later sold as ObjectSight.  I wrote a basic requirements document, and proceeded to develop the OPF, reworking it over time as I came across other ideas from Seleqt, Techinsite, Phillip Brown, Thomas Buxton, Frank Shearer, Chris Lichti, and participants of the Obiwan project and Object Oriented Design discussion groups.

I am happy to say that I licensed an earlier version of this framework to a client, and have used it on numerous projects myself, including one for the company at which I currently work.  I love the fact that I don’t have to write SQL and the more I use the framework, the better it gets.  The latest improvements include support for practically any non-data aware control via the MGM pattern.  It also supports the DevX suite of controls including their very powerful grid by way of a custom datasource.  I have dubbed the framework hcOPF where hc stands for Hengen Computing.