My Top 10 Aurelius Features - #9 Plain Old Delphi Objects

My number 9 feature of My Top 10 Aurelius Features refers to PODO - Plain Old Delphi Objects. Or in other words, the fact that Aurelius entities are simple, clean Delphi classes.

When Aurelius project started back in mid 2011, there were some object persistent frameworks available for Delphi. At that time I was wondering why such existing ones did not catch up strongly.

There were some people using it, but I didn't feel it was something that people were embracing. And one of the reasons (in my opinion) was that to make classes to become persistent the developer needed to do some many workarounds that the class end up being cluttered with unneeded things, and coding with that class was not very pleasant.

Imagine writing business code with the class below:

type
  TContact = class(TORMBaseClass)
  private
    FId: TORMInteger;
    FName: TORMString;
    FCountry: TORMRelationship;
    function GetId: TORMInteger;
    procedure SetId(const Value: TORMInteger);
    function GetName: TORMString;
    procedure SetName(const Value: TORMName);
    function GetCountry: TORMRelationship;
    procedure SetCountry(const Value: TORMRelationship;
  public
    constructor Create(SpecificParams: TORMINit); override;
    destructor Destroy;
    procedure Save(Context: TORMContext); override;
    procedure Update(Context: TORMContext); override;
    procedure Delete(Context: TORMContext); override;
  published
    property Id: TORMInteger read GetId write SetId;
    property Name: TORMString read GetName write SetName;
    property Country: TORMRelationship read GetCountry write SetCountry;
  end;

And compare to using this class when writing your code:

type
  TContact = class
  private
    FId: integer;
    FName: string;
    FCountry: TCountry;
  public
    property Id: integer read FId write FId;
    property Name: string read FName write FName;
    property Country: TCountry read FCountry write FCountry;
  end;

The first code is not specific to any other persistent framework. Actually, it's really fake, it's just a combination of ideas and solutions used by several frameworks I've seen over the years. The fact that you have to inherit from a base class, override base methods in it, have a constructor implemented that initialize mappings manually, use framework-specific types instead of primitive Delphi types, and the list goes on.

Finally, having clean, pure Delphi classes allow you to extend them, like creating non-persistent properties, using pure object references to represent associations, etc. The following video gives slightly more details about that.