Skip to content
This repository has been archived by the owner on Sep 27, 2021. It is now read-only.

Serialize into object #8

Open
qurben opened this issue Aug 30, 2017 · 3 comments
Open

Serialize into object #8

qurben opened this issue Aug 30, 2017 · 3 comments

Comments

@qurben
Copy link
Member

qurben commented Aug 30, 2017

Add the option to save a simple PHP object into the database. For instance creating a simple Email object which can only contain a valid email address.

Such class would look something like the following:

class Email extends PersistenceObject {
  /** @var string **/
  protected $email;

  /**
   * @param string $email;
   */
  public function __construct($email) {
    $this->assertValidEmail($email);
    $this->email = $email;
  }
  
  public function getValue() {
    return $this->email;
  }
}

abstract class PersistenceObject {
  abstract public function __construct($value);
  abstract public function getValue();
}

The objects should require one required constructor argument and implement the getValue method.

When defining a model the definition would look something like:

protected static $persistent_attributes = [
  'email' => [T::Object, true, Email::class],
];

Or just, where the orm checks if the type is instantiable (subclass of PersistenceObject)

protected static $persistent_attributes = [
  'email' => [Email::class],
];
@brussee
Copy link

brussee commented Jan 27, 2018

I prefer normalization of the data. E.g. Use #2 with an (UU)ID attribute.

@qurben
Copy link
Member Author

qurben commented Jan 27, 2018

The idea here is to have more control over the value a specific field can have.

With this you can have an attribute which is put into an Email class which checks if the field looks like an email address. Same could be done with a UuidUid object, which makes sure that the length is 4 and can give back information about the UuidUid, like lichting.

With this it should be easier to validate data from the database and have a clear location where this validation is done.

EDIT: Changed Uuid to Uid, got them mixed up in my head.

@brussee
Copy link

brussee commented Jan 28, 2018

I see; then I would advise to actually limit this functionality to just the validator function, and build an interface that generalizes the PersistentEnum validator functionality (from just listing the possible values in the latter case obviously).
More information about the value is coming too close to what an Entity is: a description of a particular section of the domain model.

As a side note: the UUID is(/was?) used as [primary-key]@[entity-model-plural].[domain-name].[top-level-domain]

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants