Introducing Persient...

Article recovered from my ancient blog.

.. an object persistence abstraction layer and "data schema generator" for the .NET Framework.

First off, I originally started this last summer as my Bachelor's thesis at Oxford Brookes University. What I wanted: a generalized, unified mechanism for transparent, non-redundant persistence of managed objects.

What do I mean by that?

  • Generalized and Unified—it does not always have to be an RDBMS. I wanted a simple, efficient, and above all controllable core set of persistence functionality, like Insert, Update, Delete, and Load (with object-oriented querying), which could work with an XML data source just as well as with any RDBMS or other structured permanent storage. Plus, I wanted unified, object-oriented support for querying, transactions and cursors.
  • Transparent—complete control when and how requests are sent to the data source, without having to deal with its implementation details and peculiarities. (This also means: not incurring the often-discussed performance hit of most persistence layers, which maintain costly caches to determine whether object properties have changed.) Furthermore: the ability to accurately represent all (applicable) object-oriented concepts at the permanent storage level AND at the query language level: polymorphism, inheritance, all kinds of associations. No requirement for the objects to implement a base class or set of interfaces.
  • Non-redundant—most persistence layers require you to do all the object-relational mapping yourself, by manually editing XML configuration files or using a GUI tool. This is fine when you need to access legacy or third-party data schemas, or when you have a DBA / SQL guru around who desparately wants to participate in a project. Otherwise, however, you are left with a solution that enforces great redundancy when designing the information model, which is represented in (1) the object model, (2) the data schema, and (3) the mapping files. To overcome this, you would need to scrap the middle layer and have either end be generated using the information provided by the other end. Code generators are one popular solution: the object-model code is generated from the data schema. However, I was more interested in the other way around: generating the data schema from the object model. There aren't any .NET persistence layers out there for this approach (or do you know any?) I like this approach much more, it actually has only one major drawback I can see, and that needs addressing by the Persient project: how to update the data schema from a changed object model without losing existing data (make that object instances).

I worked on Persient for quite a few months part-time, and it progressed well. It is now in this weird state of being already quite stable and quite complete, but still not quite. Suffice it to say, I'm already using it in a commercial, web-based enterprise project (improving it as I go along). So what's next for Persient?

I'm planning to release it as a product, but it needs A LOT more polish, stabilization, optimization, refactoring, and above all documentation, plus some additional features that weren't urgent enough for my purposes yet.

I will soon post:

  • a revised functional and a technical specification for Persient.
  • details about one of my personal features, the OQuery language that is an evolution from Microsoft's original OPath proposition from the now-abandoned ObjectSpaces project (it really is quite different from OPath now, just like the current OPath language, now part of WinFS, is quite different from this original spec that was my starting point).