NAME

Class::PObject::Philosophy - Philosophy behind object persistence

OVERVIEW

Idea behind Object Persistence is to represent data as a software object. Another way of looking at it is, to make objects persist across processes instead of simply being destroyed exiting the scope.

MORE ABOUT DATA

In a plain text database, for instance, each line could represent a single record. Different pieces of the record could be separated by some commonly agreed delimiter, such as a comma (,), pipe sign (|) etc. Unique identifier for individual records can be the line number that particular record resides on. For example:

    # in person.txt
    Sherzod Ruzmetov, sherzodr[AT]cpan.org
    Leyla Ivanitskaya, leyla[AT]handalak.com

In a BerkeleyDB (or DBM) each key/value pair of the hash can be considered a single record. A unique identifier for individual records can be the key of the hash. Pieces of records could be delimited by a commonly agreed delimiter, just like in a plain text database. For example:

    # in person.db
    217  => "Sherzod Ruzmetov|sherzodr[AT]cpan.org"
    218  => "Leyla Ivanitskaya|leyla[AT]handalak.com"

In a Relational Database System, each row of a database table is considered a single record, and each piece of the record has its own column in the table. A unique identifier for individual records can be a single column marked as primary key, or multiple columns marked so:

    # in person
    +-----+----------------+------------------------+
    | id  | name           | email                  |
    +-----+----------------+------------------------+
    | 217 | Sherzod        | sherzodr[AT]cpan.org   |
    +-----+----------------+------------------------+

As you noticed, they all have something in common - they all have the same logical structure, a record identifier, several pieces of different records, and a container (single line, key/value pair or a single row).

DATA AS OBJECTS

All above representations are low-level. Why couldn't we try to represent them all as a software object and forget what they really look like in the disk?

For example, we could treat a single record from either of the above databases as an object, say a Person object. According to above databases, this object may have three attributes, id, name and email. Sounds so natural, doesn't it?

Your programs, instead of dealing with low-level disk access each time a record should be accessed (for either writing or reading purposes), could just play with objects. And those objects could deal with low-level disk access behind the scenes.

WHAT ARE THE ADVANTAGES

First off, data, regardless of the storage mechanism, is always accessed through the same programming API. So your programs can work with any database system without any change at all.

Will help make a cleaner code base, because your application will never be making use of any low-level procedures to access the data such as running any SQL queries. Everything happens through objects and their supported methods.

Your applications will be more modular and code base will be more compact. As a developer you will have less code to maintain.

Your programming API will be easily accessible by 3rd parties, thus making your applications easily integrative as well as extensible without having to undergo time consuming, costly training. All they will need to read is about a page of POD manual of your related class in order to be able to make use of it.

WHAT ARE THE DISADVANTAGES

Object API may not be able to provide all the flexibility and optimization of the underlying database engine. To remedy this some tools provide sort of backdoors for the programmers to be able to interact with the underlying database engine more directly.

SEE ALSO

Class::PObject::PObject, Class::DBI, SPOPS, Alzabo, Tangram

COPYRIGHT AND LICENSE

For author and copyright information refer to Class::PObject's online manual.