Can we consider an ORM architecture to ease and beautify data handling?

[almasaeed2010]

Currently, our code have lots of repeated logic, long functions with too many parameters and no structure when it comes to defining indices. If we introduce an ORM-like architecture, we would solve the majority of these issues. A base Index (equivalent to Model in traditional ORMs) would handle defining the data mappings (columns), querying the index and creating new records. It would also provide a way to sanitize and protect against malicious code.

Example Index class:

namespace ES\Indices;

class Entity extends Index {
  protected $fields = [
    'content',
    'entity_id'
    'bundle_label'
  ];
  
  /**
   * Get the related entity
   *
   * @return object
   */
  public function entity($fields = []) {
    return tripal_load_entity('TripalEntity', $this->entity_id, false, $fields);
  }
}

[almasaeed2010]

Structure proposal (from the includes folder):

• Common
  • Instance
  • Request
  • Response
  • Queue
• Jobs
  • Job class: launches queue-able jobs.
• Query
  • Builder: builds query parameters
• Indices
  • Index class: Handles index definition and data manipulation. Depends on Query\Builder.

Register an SPL loader

Since we will have classes that depend on each other, it is likely that we'll need to load the classes in a certain order, which can cause fatal errors if the order is wrong. PHP provides a solution for this, SPL loaders. The loaders trigger a function when a class has been called but was not found. The function can handle the loading of the class as needed. This requires that we define all our classes within a namespace as such: ES\Common, ES\Jobs, etc. Then, when a class that belongs to the ES namespace is encountered, we will attempt to check if the file exists and load it. If it does not exist, let php handle the rest (throw an error or find another SPL loader).

See this post for an example.

[almasaeed2010]

Follow up in PR #242