Współpraca Entity |
Współpraca Entity |
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ć. |
|
|
16.06.2018, 11:58:34
Post
#2
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
Wydaje mi się, że za bardzo skupiasz się w tej chwili na Symfony/Doctrine/innych bibliotekach oraz na problemach których jeszcze nie masz tworząc z relatywnie prostego problemu rozdmuchanego potwora, do którego faktycznie trudno podejść. Wcześniej pisałeś o tym jak już oczami wyobraźni widzisz strukturę i kontrakty pomiędzy obiektami, teraz piszesz o nieistotnych z punktu widzenia tego problemu bzdetach. Zignoruj na chwilę problem obsługi bazy danych czy ogólnie ich składowania. Olej problem wprowadzania danych czyli formularze. Wypnij cztery litery na tworzenie serwisów w kontenerze zależności zrób to manualnie na start.
W skrócie: utwórz sobie prosty, śmieciowy kontroler z jedną akcją jako punkt wejścia do kodu, wpisz do niego ręcznie jakiś stan początkowy dla danych, uruchom kod który ma te dane przetworzyć i na koniec nawet najprostszym Symfonowym dump() wyświetl rezultat by sprawdzić czy otrzymane dane są prawidłowe.
Utwórz sobie kilka takich akcji, które pozwolą Ci zweryfikować czy istotny kod Twojej aplikacji działa poprawnie. Jak ten problem będziesz miał rozwiązany będzie można przejść do tematu zapisu jakiś danych do bazy - ale wtedy zobaczysz, że nie będziesz już musiał sobie w ogóle zaprzątać głowy obliczeniami i kod znowu będzie prosty. Później rozwiążesz sobie problem wydobycia danych z bazy czy np. z formularzy - dwa kolejne problemy do osobnego rozpatrzenia. I tak dalej i tak dalej. W tych późniejszych zadaniach Symfony/Doctrine mocno ułatwią Ci pracę, bo te problemy adresują i potrafią rozwiązywać - ale to później. "best practices" mają zastosowanie dopiero w momencie korzystania z elementów Symfony/Doctrine - ale to zaś: później. Pamiętaj też, że nad nimi powinny stać "best practices" pisania kodu samego w sobie, a to już jest mocno niezależne od bibliotek, frameworków czy nawet języków. PS. Jeśli zamienisz sobie śmieciowy kontroler na klasę testu jednostkowego, a dump() na serię assert() będziesz miał książkowy przykład TDD w stylu AAA. :-) |
|
|
Wersja Lo-Fi | Aktualny czas: 10.06.2024 - 23:26 |