[SF][SF2][Symfony2] proste sprawy związane z architekturą |
[SF][SF2][Symfony2] proste sprawy związane z architekturą |
13.10.2013, 15:29:55
Post
#21
|
|
Grupa: Nieautoryzowani Postów: 2 249 Pomógł: 305 Dołączył: 2.10.2006 Ostrzeżenie: (0%) |
Złe jest dlatego, że nadajesz repozytorium kolejną zależność (musisz tą zależność dostarczać przy pisaniu testów). Dodatkowo obciążając to repozytorium kolejnym zadaniem. Co gorsze zależność ta jest związana z jednym z kontekstów uruchamiania aplikacji (http), jeśli chciałbyś takie repozytorium wykorzystać podczas uruchamiania aplikacji z konsoli to masz problem. Z kontekstem zgoda jak najbardziej, z zależnością już nie do końca. Najlepiej tak czy siak, taką funkcjonalność po prostu przenieść do serwisu, a w repozytorium tylko dane wybierać. Tylko teraz już nie słuchaj pedro84 (to oczywiście tylko moje zdanie) i nie twórz klasy CartManager tylko po prostu Cart. W innym wątku (dot. właście czy KlasaManager czy Klasa) dobrą czytankę Ci wkleiłem dlaczego Manager. Ad vocem konwencji, to już dyskusja o wyższości jednych świąt na drugimi -------------------- Google knows the answer...
|
|
|
13.10.2013, 17:39:00
Post
#22
|
|
Grupa: Zarejestrowani Postów: 879 Pomógł: 189 Dołączył: 14.06.2006 Skąd: Bytom Ostrzeżenie: (0%) |
Cytat Z kontekstem zgoda jak najbardziej, z zależnością już nie do końca. Nie wiem co oznacza, że już nie do końca. Nie do końca się zgadzasz, że kolejna zależność (całkowicie niepotrzebna) jest złą praktyką? Cytat Najlepiej tak czy siak, taką funkcjonalność po prostu przenieść do serwisu, a w repozytorium tylko dane wybierać. Od tego się zaczęła między nami dyskusja i od początku miałem taki punkt widzenia. Cytat W innym wątku (dot. właście czy KlasaManager czy Klasa) dobrą czytankę Ci wkleiłem dlaczego Manager. Też wkleiłem tam czytankę i co z tego? To są tylko czyjeś opinie takie same jak moje. Poza tym można tam znaleźć argumenty za i przeciw. W tamtym wątku menadżer dotyczy zarządzania kolekcją, np. użytkowników, Ty postulujesz użycie menadżera do obsługi jednego koszyka. Jak na warunki SO to słabo punktowany wątek, a w dodatku zamknięty. |
|
|
16.10.2013, 00:50:45
Post
#23
|
|
Grupa: Zarejestrowani Postów: 896 Pomógł: 76 Dołączył: 15.11.2003 Skąd: Sosnowiec/Kraków Ostrzeżenie: (0%) |
Dzięki, rozjaśniło mi to trochę spraw. Chyba po prostu dotychczas nie dotarło do mnie, że aż tak elastyczna jest struktura bundla.
Chciałbym się w takim razie upewnić, czy zrobiłem to dobrze: mam teraz obiekt Cart, zarejestrowałem go jako service i mam do niego dostęp w kontrolerze. Tenże Cart ma metodę contains($productId), która sprawdza, czy koszyk zawiera produkt. W kontrolerze podaję do twiga tablicę produktów oraz Cart (service). W twigu sprawdzam czy dany produkt jest w koszyku poprzez {% if cart.contains(product.id) %}. Działa - czy prawidłowo? Nie jestem pewien tej części, w której przekazuję service do twiga. I jeszcze pytanie dodatkowe: czy istnieje rozwiązanie, w którym sprawdzałbym w twigu {% if product.inCart %} ? Czy musiałbym wtedy stworzyć po prostu metodę inCart w repozytorium produktu, a następnie użyć w niej service cart? Czy to nie byłoby lepsze ze względu na to, że nie musiałbym w kontrolerze przekazywać service cart do twiga? Czy da się to zrobić bez service? Ten post edytował Foxx 16.10.2013, 00:54:44 |
|
|
16.10.2013, 18:25:11
Post
#24
|
|
Grupa: Zarejestrowani Postów: 879 Pomógł: 189 Dołączył: 14.06.2006 Skąd: Bytom Ostrzeżenie: (0%) |
Rozważ sobie czy nie lepiej do metody Cart::contains() zamiast id produktu nie lepiej byłoby przekazywać cały produkt. To jest luźna propozycja.
Co do samego Twiga. Możesz sobie taki koszyk podpiąć jako zmienną globalną. Możesz też podejść do tego jeszcze w ten sposób, że koszyk jest powiązany z obecnie zalogowanym użytkownikiem. Dorzucasz użytkownikowi gettera do koszyka. Sam użytkownik już z marszu jest w Symfony2 globalny więc odpada problem każdorazowego podpinania zmiennej do szablonu. Cytat czy istnieje rozwiązanie, w którym sprawdzałbym w twigu {% if product.inCart %} ? Wtedy do encji musiałbyś podpiąć sesje. Bez sensu totalnie. Możesz napisać jaki jest powód, że chcesz akurat taki zapis? |
|
|
19.10.2013, 00:33:22
Post
#25
|
|
Grupa: Zarejestrowani Postów: 896 Pomógł: 76 Dołączył: 15.11.2003 Skąd: Sosnowiec/Kraków Ostrzeżenie: (0%) |
Dzięki, podoba mi się pomysł połączenia usera z koszykiem.
Co do argumentu dla Cart::contains() to zastanawiałem się, czy to powinien być produkt czy tylko jego id skoro korzystam tylko z id, ale nie jestem w stanie określić, które rozwiązanie jest lepsze. Wybrałem id bo wydawało mi się to mniej obciążające pamięć, ale tak naprawdę to nie wiem czym się kierować w takim wypadku. Pytam o rozwiązanie product.inCart bo taki zapis, a konkretnie taki sposób operowania tymi obiektami wydaje mi się najbardziej sensowny: przetwarzam kolejne produkty i pierwsze co mi przychodzi do głowy to odpytanie właśnie produktów o ich status koszykowy. Odpytywanie koszyka wymaga kolejnego obiektu (koszyka). Albo inaczej mówiąc wydaje mi się sensowne żeby produkt wiedział na swój temat takie rzeczy. |
|
|
Wersja Lo-Fi | Aktualny czas: 20.04.2024 - 04:44 |