From tabular to a tree, my way of ORM for a PHP code – Part two

In my previous post I described what an ORM is, now it’s time to explore different types of it in regard to PHP.

Different types of an ORM

I already mentioned that the main purpose of an ORM is to translate between objects and database records, but most of the times that’s not all what they do. Mostly they try to be more, having this said, there are all sorts of ORM projects out there with all sorts of perks and benefits, and I’m not going to list them. Instead I’m going to list different characteristics shared by most of them. Before we start, bear in mind that I’m talking ORMs in PHP!

  1. Code generators: These ORMs take a database schema (either as an SQL file or a database connection) and create the corresponding classes to match the tables in the database schema. Best case scenario, there will be setter and getter methods to access the fields retrieved, and that’s completely acceptable! I mean how could the code generator guess your business logic to write in the generated class!? You need to understand that this process does not happen when your code is running, but while you are still coding, i.e. one time library. These ORMs usually come with run-time libraries helping you actually translating the data to / from database.
  2. Database schema generators: These are looking at the problem from the other side. Such ORMs try to create your database schema given a bunch of classes. They would assume that you are capable of writing your own class hierarchy but not the database schema. And again they usually come with run-time libraries helping you translate objects to records and vise versa.
  3. Query composers: While the two previous types of ORMs come with facilitators to be run at design time of your code, this one only provide you with run-time code. In this case, ORM tries to eliminate the developer’s need to know SQL. Instead it will provide him / her with a bunch of method calls which will lead to SQL generation on the fly. And of course it comes with parts helping you with the ORM’s actual job, the mapping.

Why I think each of the mentioned features are gone wrong:

  1. Code generators: Writing down a bunch of setters and getters and a list of properties solves nothing! You can easily write a unique class and return objects instantiated of it regardless of the entity’s type:
    <?php
    class Entity
    {
      protected $data = array();
      public function __set($key, $value)
      {
        if (!array_key_exists($key, $this->data)) {
          throw "trying to set undefined field: $key";
        }
    
       $this->data[$key] = $value;
      }
    
      public function __get($key)
      {
        if (!array_key_exists($key, $this->data)) {
          throw "trying to get undefined field: $key";
        }
    
        return $this->data[$key];
      }
    }
    

    Also PHP does not let you provide type for class properties which is another reason why my way is exactly the same like defining a dedicated class for each entity. All the downsides aside, who said there’s always a one to one relation between tables in database and classes in code!?!?

  2. Database schema generators: This approach is much worse than the previous one! Designing a database based on the given code is the most ridiculous thing I’ve ever heard! Designing a database is a delicate task and it can not be automated, period. If you think you can not do it yourself, hire someone who can, don’t use an automation library for it. It’s just going to make things worse for you. It’s much better to serialize all your objects into one big text file rather than going down this way!
  3. Query composers: This solution amazes me! If someone knows how to compose a query using PHP code, why they can’t do the same in SQL!? SQL is a really powerful tool and if you can’t use it maybe RDBMS is not for you! I admit that one use case for query composers is to write one code and generate SQL for different RDBMSs (at least in theory), but by using such replacements you sacrifice so much, there’s so much in SQL that you can not do the same with a query composer. And believe me in my past 14 years of experience that I’ve got in this field, I’ve never faced the situation to change from one RDBMS to another. I’m not saying that such a need would never arise, I’m just saying that if you face such a need then chances are your project is going to fail anyway, and you’ll never get the chance to actually cash your investment in using a query composer.

I need to take a break, such matters make my blood boil!

OK, I’m back. Now that I crushed all the common features found in an ORM, I’m going to tell you what I look for in an ORM in the next article entitled “Appropriate features for an ORM“.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s