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

Monday, December 12, 2016

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.




Wagner R. Landgraf


Bookmarks: 

This blog post has received 4 comments.


1. Monday, December 12, 2016 at 9:27:23 PM

Excellent really is a feature of TMS Aurelius, waiting for the next post, congratulations.

Manoel Pedro Jr


2. Tuesday, December 13, 2016 at 8:21:36 AM

Wagner, i must congratulate with you: I really enjoy reading and watching your posts and videos about TMS Aurelius.
First, I appreciate them because they are very specific and up to the point.
Second, as a TMS Aurelius user, the more of your post I read, the more I am confident about the choice I have made between TMS Aurelius and "The Others".
I love the simplicity of TMS Aurelius: this is the very distinctive trait of it: If you know how to deal with Plain Old Simple Object in Delphi, then you know 80% of TMS Aurelius. And your posts about it, are something I always find very interesting.
Thank you so much.
--
Fabio Vitale

Fabio Vitale


3. Wednesday, December 14, 2016 at 1:39:28 AM

Thank you very much for your words, Fabio. Really appreciated.

Wagner R. Landgraf


4. Wednesday, December 14, 2016 at 1:40:00 AM

Thank you Manoel Pedro Jr, stay tuned for the next posts!

Wagner R. Landgraf




Add a new comment:
Author:
Email:
  You will receive a confirmation mail with a link to validate your comment, so please use a valid email address.
Comment:
 
Change Image
Fill in the characters from the image above:
 

All fields are required.
 




Previous  |  Next  |  Index