Jak się to robi? Domain model itp Opcje

[tczajka]

Witam

Mam pytanie dotyczące stosowanych praktyk w programowaniu obiektowym (chciałbym stosować domain model).

Załóżmy że mam takie domeny:

class User implements UserInterface
{
protected $id;
protected $name;
protected $login;
}
class Customer implements CustomerInterface
{
protected $id;
protected $name;
protected $address;
protected $user; // obiekt implementujący UserInterface
}
class Server implements ServerInterface
{
protected $id;
protected $name;
protected $user; // obiekt implementujący UserInterface
}
class ServerAccount implements ServerAccountInterface
{
protected $id;
protected $login;
protected $user; // obiekt implementujący UserInterface
}

do każdego mam napisanego mappera powiedzmy na bazę danych.
Teraz tworząc pojedynczy obiekt Customer setterem wstrzykuje obiekt User by ustawić użytkownika który go dodał (analogicznie w innych domenach)

Teraz pytania jak powinno się rozwiązać następujące kwestie:

1. Jeśli jedno konto może być przypisane do kilku serwerów i jeden serwer może być przypisany do kilku kont to czy robić tak że tworzę osobnego mappera np ServerAccountServerMapper gdzie wstrzykuję obiekt Server i obiekt ServerAccount czy inaczej się to robi?

2. Jak w przypadku operowania na jednej instancji obiektu wszystko cacy ale jak taka praktyka się ma w przypadku np rozbudowanych uprawnień gdzie do jedego usera przypisuję np 150 acl'ek? Przekazywać tablicę obiektów czy tablicę?

3. Jeśli pobieram jeden obiekt domeny np Customer to ustawiam sobie $user jako obiekt typu UserInterface (kto dodał) np poprzez
$Customer = $CustomerMapper->getById(123);
czyli mogę pobrać kto dodał wpis teraz przez:
$addedBy = $Customer->getUser()->getLogin();

Jak to wygląda w przypadku gdy pobieramy pełny raport (na tabelach było by to zapytanie relacyjne na 4 tabelach - users, customers, servers,, server_accounts) gdzie pobieramy m.in. informacje o użytkowniku który dodał poszczególne konta, klientów, serwery. Czyli przy dużej ilości danych jeden user może wystąpić dziesiątki razy bo dodał kilka kont, kilku klientów itp.
Mamy powiedzmy metodę ->fetchFullCustomerReport() - co powinna zwracać taka metoda? Tablicę np asocjacyjną? Tablicę obiektów? Powiedzmy że tablicę obiektów Customer ale co z tymi userami? mam w tej całej zagnieżdżonej strukturze wstrzykiwać ten sam obiekt usera np 100 razy bo user dodał 100 wpisów? Jaki to ma wpływ na wydajność, ilość pamięci itp?
Jak zaleca się to pobierać?

Proszę mnie nie "rzezać" jeśli coś źle piszę, obiektówki się uczę.
pozdrawiam

[destroyerr]

1. Jeśli jedno konto może być przypisane do kilku serwerów i jeden serwer może być przypisany do kilku kont to czy robić tak że tworzę osobnego mappera np ServerAccountServerMapper gdzie wstrzykuję obiekt Server i obiekt ServerAccount czy inaczej się to robi?

O ile dobrze zrozumiałem to pytasz o relację wiele do wielu. Dla tablicy łączącej nie pisałbym osobnego mapera, bo nie masz czego mapować.

2. Jak w przypadku operowania na jednej instancji obiektu wszystko cacy ale jak taka praktyka się ma w przypadku np rozbudowanych uprawnień gdzie do jedego usera przypisuję np 150 acl'ek? Przekazywać tablicę obiektów czy tablicę?

Tablicę obiektów. Pytanie gdzie chcesz je przekazywać. Moim zdaniem w takim wypadku lepiej byłoby dorzucić osobną usługę, która zajmowała by się sprawdzeniem tych uprawnień dla przekazanego użytkownika. Sposób w jaki pobierała by te aclki to już jej sprawa, mógłby być getter na użytkowniku lub jakaś metoda z repozytorium aclek i wtedy możesz sobie zwracać co chcesz. Jeżeli stwierdzisz, że Twoja aplikacja działa wolno z tego powodu to łatwo możesz to sobie przepisać.

3. Jeśli pobieram jeden obiekt domeny np Customer to ustawiam sobie $user jako obiekt typu UserInterface (kto dodał) np poprzez
$Customer = $CustomerMapper->getById(123);
czyli mogę pobrać kto dodał wpis teraz przez:
$addedBy = $Customer->getUser()->getLogin();

Jak to wygląda w przypadku gdy pobieramy pełny raport (na tabelach było by to zapytanie relacyjne na 4 tabelach - users, customers, servers,, server_accounts) gdzie pobieramy m.in. informacje o użytkowniku który dodał poszczególne konta, klientów, serwery. Czyli przy dużej ilości danych jeden user może wystąpić dziesiątki razy bo dodał kilka kont, kilku klientów itp.
Mamy powiedzmy metodę ->fetchFullCustomerReport() - co powinna zwracać taka metoda? Tablicę np asocjacyjną? Tablicę obiektów? Powiedzmy że tablicę obiektów Customer ale co z tymi userami? mam w tej całej zagnieżdżonej strukturze wstrzykiwać ten sam obiekt usera np 100 razy bo user dodał 100 wpisów? Jaki to ma wpływ na wydajność, ilość pamięci itp?
Jak zaleca się to pobierać?

Dużo problemów na raz. Przede wszystkim zawsze obiekty. O tablicach zapomnij.
Skoro użytkownik jest ten sam to w całej aplikacji (w obrębie jednego żądania) powinien być jeden obiekt. Co do wydajności to przecież możesz to sobie sam sprawdzić.

[tczajka]

Bardzo dziękuję Ci za zdanie w temacie.

O ile dobrze zrozumiałem to pytasz o relację wiele do wielu. Dla tablicy łączącej nie pisałbym osobnego mapera, bo nie masz czego mapować.

Tak wiele do wielu. Ok, czyli np serverMapper mógłby przyjmować tablicę obiektów kont do przypisania.

Tablicę obiektów. Pytanie gdzie chcesz je przekazywać. Moim zdaniem w takim wypadku lepiej byłoby dorzucić osobną usługę, która zajmowała by się sprawdzeniem tych uprawnień dla przekazanego użytkownika. Sposób w jaki pobierała by te aclki to już jej sprawa, mógłby być getter na użytkowniku lub jakaś metoda z repozytorium aclek i wtedy możesz sobie zwracać co chcesz. Jeżeli stwierdzisz, że Twoja aplikacja działa wolno z tego powodu to łatwo możesz to sobie przepisać.

Przepraszam za lamerskie pytanie, jak wspomniałem początkuję, co masz na myśli przez "usługę"? Tzn dosłownie chyba to co dalej napisałeś że byłoby to załatwiane przez tutaj do ustawiania - setter.

Dużo problemów na raz. Przede wszystkim zawsze obiekty. O tablicach zapomnij.
Skoro użytkownik jest ten sam to w całej aplikacji (w obrębie jednego żądania) powinien być jeden obiekt. Co do wydajności to przecież możesz to sobie sam sprawdzić.

Problemów dużo bo i aplikacja trochę rozbudowana i doświadczenie w temacie małe. Wszelkie przykłady z jakimi się spotkałem w sieci opierają się na pojedynczych instancjach obiektów a ja mam w przypadku projektowanej aplikacji prace często na dość złożonych (bardziej pasowało by napisać zagnieżdżonych) strukturach danych gdzie często muszę zrobić relacje wiele do wielu na 5-10 tabelach. Pisząc proceduralnie robiło się z tego jedną wielką tablicę z którą później iterując mogłem zrobić różne rzeczy: wyświetlić, zapisać itp. A na obiektach wydaje mi się to dużo bardziej złożone i pracochłonne.

[thek]

Usługa, to zapewnie Service, czyli dodatkowa klasa, której zadaniem byłoby, na podstawie znajomości systemu uprawnień, sprawdzanie co może użytkownik, do czego ma dostęp i na podstawie tego co wie zabraniać lub zezwalać na działanie określone względem zasobów o które prosi. To coś na zasadzie łącznika między acl i userem.
.