Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Współpraca Entity
athabus
post 4.06.2018, 14:39:05
Post #1





Grupa: Zarejestrowani
Postów: 898
Pomógł: 48
Dołączył: 2.11.2005
Skąd: Poznań

Ostrzeżenie: (0%)
-----


Mam takie pytanie teoretyczne, które od czasu do czasu pojawia się w moich projektach. Najlepiej chyba będzie opisać na przykładzie.

Piszę aplikację sportową (konkretnie dla pływaków) we frameworku Symfony i w niej mam między innymi dwa obiekty Entity:
- User
- Interval

Użytkownik ma pewne cechy definiowalne - np. prędkość bazową (dajmy na to 2:00/100m), modyfikatory prędkości (np. gdy ma płetwy to płynie 10s/100m szybciej niż bez etc).

Interwał to cegiełka z której buduję treningi do wykonania. Czyli każdy interwał posiada między innymi:
- dystans do pokonania
- prędkość wyrażoną jako prdkość bazowa +/- x sekund.
- listę modyfikatorów do zastosowania - czyli np. dany interwał użytkownik ma płynąć w płetwach

I teraz dochodzimy do tego co mnie interesuje. Mam konkretny interwał w którym jest płyń z prędkością bazową - 5s oraz użyj płetw. Mam konkretnego użytkownika, dla którego prędkość bazowa to 2:00, a modyfikator płetw daje - 10s. Czyli finalnie ten konkretny użytkownik ma popłynąć ten konkretny interwał w tempie 2:00 (prędkość bazowa użytkownika) - 5s (ustawienie interwału) - 10s (bonus za płetwy) - razem daje 1:45/100m.

Pytanie brzmi - jaki obiekt powinien obliczyć tą konkretną wartość, żeby było prawidłowo i zgodnie ze sztuką.

Interwał raczej nie powinien wiedzieć o użytkowniku i vice versa. Robienie tych samych obliczeń w 50 miejscach (np. w kontrolerach) jest bez sensu i trudne w utrzymaniu. Osobiście w tym celu stosuję usługę, którą sobie nazwałem WorkoutService i mam tam takie funkcje jak np getIntevalPace.

Zastanawiam się czy to jest dobre rozwiązanie, czy może jakoś inaczej powinienem to ogarniać.

Go to the top of the page
+Quote Post
 
Start new topic
Odpowiedzi
Crozin
post 11.06.2018, 10:05:18
Post #2





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----


1. Nie bój się tworzyć wielu dedykowanych klas do rozwiązywania wielu różnych problemów w aplikacji. Unikaj raczej tworzenia "obiektu pod wszystkie możliwie zadania", bo to się nie sprawdza.
2. Staraj się by raczej detal implementacji warstwy zapisu danych (tutaj: baza danych + doctrine) nie wyciekał do innych warstw aplikacji. Innymi słowy obiekty domenowe same w sobie raczej nie powinny - bo i po co - mieć wiedzy n/t Doctrine'a.
Cytat
W innej części aplikacji mam np. bardziej rozbudowany serwis służący do generowania komend głosowych - korzysta on z serwisu zewnętrznego do generowania komend głosowych, z serwisu dokonującego tłumaczeń itp. Czy teraz obiekt workout powinien także takie rzeczy robić jak generować pliki dźwiękowe?
Tutaj musiałbyś lepiej przybliżyć sytuację.
Cytat
Czytając trywialne przykłady omawiające różne wzorce projektowe, gdzie klasy są na 5 linijek, a przykłady mocno uproszczone wszystko wydaje się oczywiste - ale jak trafia na normalną aplikację, to to wszystko przestaje być już oczywiste.
Dużą sztuką jest doprowadzić do tego by skomplikowany problem przedstawić w ujęciu trywialnego kodu. To jest jedna z trudniejszych umiejętności do nabycia.

IMHO zacznij sobie te problemy rozwiązywać po kolei, szybko prototypując. Pomiń na chwilę warstwę zapisu danych do bazy, skup się na problemie. Jak to będzie zrobione będziesz mógł przejść dalej, tj. do zapisu.
Go to the top of the page
+Quote Post

Posty w temacie


Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 23.04.2024 - 22:08