[Doctrine] Konwertowanie kolumny encji na obiekt Opcje

[ghost1511]

Dopiero zaczynam swoją przygodę z Doctrine i natknąłem się na następujący problem.

Załóżmy, że mamy następującą encję:

[PHP] pobierz, plaintext 
<?php
 
use Doctrine\ORM\Mapping as ORM;
 
/**
 * @ORM\Entity
 * @ORM\Table(name="users")
 */
class User {
 
  /**
   * @ORM\Id
   * @ORM\GeneratedValue
   * @ORM\Column(type="integer")
   */
  private $id;
 
/**
 * @ORM\Column(type="string")
 */
private $email;
 
}
[PHP] pobierz, plaintext 

Jak widać User posiada dwa pola

Kod

id (int)

i

Kod

email (string)

. Encja będzie dzialać. Ja natomiast nie chcę aby email był typu string. Chciałbym aby w tym obiekcie email był na przykład obiektem typu Email. W jaki sposób mogę zautomatyzować tę konwersję?

W dokumentacji znalazłem to, ale wydaje mi się, że nie do tego to służy.

[skowron-line]

Jeżeli w bazie w kolumnie email bedziesz trzymał email (string) to jest to string, jeżeli referencje do innej tabeli to bedzie tam Mapping.
Możesz też zrobić tak

[PHP] pobierz, plaintext 
setEmail(EmailObject $email)
{
  // toString czy co tam chesz
}
[PHP] pobierz, plaintext 

[ghost1511]

Ale nie ma żadnej możliwości żeby obiekt ten encji posiadał EmailObject pod emailem? nie chodzi mi o to aby ręcznie ustawić EmailObject przez setter, tylko żeby encja po pobraniu z bazy od razu konwertowała string na EmailObject.

[destroyerr]

Link, który podałeś, służy do rozwiązania Twojego problemu. W taki sposób Doctrine konwertuje daty.

Jeżeli w bazie w kolumnie email bedziesz trzymał email (string) to jest to string, jeżeli referencje do innej tabeli to bedzie tam Mapping.

Nie mogę się z tym zgodzić. Doctrine nie ma służyć do zmiany danych z bazy na obiekty, tylko ma utrwalać obiekty w bazie danych. Nie można skupiać się na tym co ma być w bazie tylko na tym co będzie utrwalane. Utrwalanie to ma być przezroczyste, tak jakby w ogóle nie było żadnej bazy danych a obiekty istniały cały czas pomiędzy każdym wywołaniem skryptu.

[ghost1511]

Nie mogę się z tym zgodzić. Doctrine nie ma służyć do zmiany danych z bazy na obiekty, tylko ma utrwalać obiekty w bazie danych. Nie można skupiać się na tym co ma być w bazie tylko na tym co będzie utrwalane. Utrwalanie to ma być przezroczyste, tak jakby w ogóle nie było żadnej bazy danych a obiekty istniały cały czas pomiędzy każdym wywołaniem skryptu.

Czyli co? Czy ja źle pojąłem ideę Encji (Entity) i nie może ona być traktowana jako model? A jedynie ma być ono odwzorowaniem jednego wiersza z tabeli bazy danych. Ignorując w ogóle logikę aplikacji?

Ten post edytował ghost1511 3.10.2014, 09:15:11

[Pyton_000]

To co pokazałeś nada się. Przy odczycie konwertujesz do obiektu a przy zapisie do string i tyle.
W laravel w modelu istnieje możliwość użycia Mutatorów np:

[PHP] pobierz, plaintext 
function setEmailAttributes($email){}
function getEmailAttributes(){}
[PHP] pobierz, plaintext 

[ghost1511]

No dobra... W tym przypadku mógłbym utworzyć nowy typ i go odpowiednio konwertować. A teraz taki przypadek:

Rekordy bazy danych:

Kod

EMAIL              NAME           ROW_DATE
it@noname.pl       It office      2014-11-03 00:00:00
office@noname      Some name      2014-11-12 00:00:00

[PHP] pobierz, plaintext 
class EmailObject{
public $emailAddress;
public $name;
}
[PHP] pobierz, plaintext 

Czy teraz jest możliwa konwersja typów? Tzn z tabeli EMAIL i NAME lądują w obiekcie EmailObject, a po zmianach zapis ląduje w odpowiednich kolumnach w bazie?

Jedyne co mi przychodzi do głowy to w encji usunąć (lub zmienić na prywatne) funkcje getEmailAddres, i getName(). Utworzyć publiczną funkcję getEmailObject korzystający z pól encji.

Ten post edytował ghost1511 3.10.2014, 09:53:14

[destroyerr]

Teraz to już nie wiem co chcesz zrobić, ale skoro obiekt reprezentujący adres mailowy ma mieć więcej właściwości to musisz zrobić tak jak sugerował skowron-line, czyli wykorzystać mapowanie relacji w Doctrine.