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


Plain Old Delphi Objects is number 9 of my top ten Aurelius features and it refers to the way that entity classes are built and supported by the framework. When Aurelius development started, many years ago, one thing that bothered me about the existing frameworks was that the class used to represent the entity was very confusing. This is an example of an hypothetical ORM library this is, of course, not a real library, but it’s a list it’s like a list of all the strange and bad and confusing things I’ve seen in other frameworks which is a lot of things that the framework requires you to write in the class for it to work. So imagine that this is a TContact entity class with properties Id, Name and Country. So there are a lot of problems between codes that you might have when you use an ORM framework. The code in red shows, for example, methods for persisting the class. So, some frameworks require you to override some methods to implement some business logic or some extra things in the class itself save, update and delete methods, for example, receiving an ORM context, this is not desired. Or maybe you have your properties and you have to implement getters and setters for all of them because you have to specially know Delphi versions that RTTI are not complete. You have to maybe map the value of the database to the property and vice-versa and implement getters and setters, that is also not desired. Or even you have to… some frameworks require you to use specific types. So, for example, my Id property must be T of type T ORM integer or something like that. So, ideally, we should deal with primitive Delphi types, like integer and string. And sometimes you are maybe required to override or implement a specific constructor inherit from a base class or do something custom initializations in your class, that’s also not desired. And for associations, for example, in this class TContact, we have a country, the country of the contact, which is a relationship or association or whatever name you want to give it and it maybe needs some special type that is also not desired. So, ideally, we should only need to deal with object references so I have a contact and there is a country associated with it which is just another object of type TCountry and there is sometimes also a need to have all properties published which is not needed maybe you want to have public properties or protected properties or even you want to map fields, which represent the state of the class, and many frameworks require you to inherit your entity class for a base class. That’s not a very big deal, but sometimes you have to or want to inherit from your own class or you just want to have your entity class to be a pure Delphi class. So that’s also interesting to have. So, in the end, this is the ideal class we need. It’s a pure Delphi class with no strange things in it, specific framework things, so you can focus on your business logic. So if you take a real application as an example well, a sample application as an example, another consequence of having the ability to use simple Delphi classes is that you can simply use Delphi and you can extend that business class. So this is my Customer class, for example, and I have this property Birthday, which is being persisted in the database, and I can create simply a property Age, with a getter here that returns the age of my Customer based on the birthday. Of course, this is a very simple example, but it illustrates how you can extend your class and add business logic to it and, in summary, work with that class… with that entity class, as any entity, any Delphi class. You can add that logic to it. And another interesting thing I like is the way Aurelius deals with reference, so this is our country property, which is a reference to a country object, that’s why what you deal with relationships is just a reference Aurelius manages the memory. This is an example, let’s go back here to this form code, it’s just a sample, an example, it doesn’t do anything meaningful, but it illustrates what I’m trying to say. This code, for example, retrieves a list of customers and retrieves two countries, USA and Germany, countries of type TCountry, I just passed some code here, I could have used any query I want, This is the business code I have here. For each customer in my list, if the customer age is under 30, set the country of this customer as USA, otherwise set the country as Germany. As I said, it’s meaningless code, but it shows two things I want to illustrate, which is using the class, this is my non-persisting properties, the business property: Age, which I have shown how it’s implemented and the way it deals with associations, which is just set the country as USA, it’s the same country, you see that there’s no composition here, I don’t have to create a TCountry for every customer I want to set for the USA. It’s just a reference either for the USA or Germany. And that’s it: the object is persisted. So that’s my number 9 top feature that I can use plain simple classes for my business logic and just forget that I’m using Aurelius, I’m just using Aurelius here for retrieving the objects, but this code here, it’s simple objects. Thanks, don’t forget to subscribe to our channel to receive notifications about upcoming videos. Thanks for watching!

4 Replies to “My Top 10 Aurelius Features – #9 Plain Old Delphi Objects”

Leave a Reply

Your email address will not be published. Required fields are marked *