2011-09-02 14 views
6

Pracuję nad tą aplikacją, która uzyskuje dostęp do zmiennych sesji w warstwie modelu. To wydaje się po prostu błędne, ale jestem gotów udowodnić, że się mylę. Możliwe, że nie tak, ale w większości miejsc w aplikacji zmienne sesji są obsługiwane w kontrolerze i przekazywane jako argumenty, ale w innych miejscach dostęp do wartości sesji jest już dostępny. Czy nie mam racji, że wygląda to na złą praktykę?Projektowanie aplikacji Zend Framework - należy uzyskać dostęp do zmiennych sesji w warstwie modelu

edytuj: Jednym z powodów, dla których nie podobają mi się sesje w modelach, wydaje się, że testowanie jest bardziej skomplikowane. Zachowaj to jako tylko params przekazane do funkcji, a następnie zestaw rekordów przekazywany z powrotem.

thx

+4

Zastanów się przez chwilę, czy chcesz użyć modelu w skrypcie wiersza poleceń: bez sesji. Lub w teście jednostkowym. Jeśli potrzebujesz danych, które * mogą * pochodzić z sesji, lepiej ukryj je wewnątrz obiektu, który możesz sfałszować w przypadku użycia testu lub linii poleceń. –

+0

Nie rób tego! Warstwa danych to jedno, a logika biznesowa inna. Użyj instancji Zend_Registry lub nawet odwzorowań danych. –

Odpowiedz

4

To zależy.

Sposób myślę na ten temat jest takie:

  1. A Wzór reprezentuje warstwę danych.
  2. Przez większość czasu warstwa danych będzie bazowana na bazie danych DB
  3. Sesja to tylko kolejny nośnik danych.
  4. Wnioski: Jeśli dane, które dany model reprezentuje jest przechowywana w sesji, niż to jest OK, aby uzyskać dostęp do danych z poziomu modelu

Przykładem jest sesja oparta koszyk. Obiekty mojego koszyka są modelami danych mojej sesji.

+0

Wystarczająco fair. Ale chciałbym dodać obiekt pobierający/ustawiający dla obiektu sesji, aby móc później wyszykować. –

+0

Problem, który widzę w tej aplikacji (a więc i pierwotna motywacja), polega na tym, że # 3 NIE jest # 2 ani więcej współdziałające, nie jest utrzymywane w db i tylko w mechanizmie sesji php. W efekcie dostajesz wiszące referencje. W tym przypadku wydaje się, że bardziej sensowne jest albo uruchamianie sposobu, w jaki te specyficzne metody nie będą wywoływane, chyba że istnieje zmienna sess-> user_id (tj. Wykonany poziom kontrolera ar) LUB zarządzają przez konstruktor modeli/inicjalizację, czy użytkownik ma sess-> user_id. Jeśli chodzi o kwestie testowania i cli (oba z nich są używane), mógłbym utworzyć ręczne wartości sesji. – timpone

+0

@timpone Może nie rozumiem, co masz na myśli przez wiszące referencje. Danglingowy problem referencyjny miałby miejsce tylko wtedy, gdyby w innym modelu trwałym przechowywano identyfikator sesji jako obcy referencyjny - co jest bardziej kwestią projektowania magazynu/bazy danych. Nie odnosiłbym się do mojego stałego magazynu (bazy danych) i tymczasowego przechowywania (sesji), mimo że obie warstwy danych. To, co moja ilustracja miała na celu zilustrować, polegało na tym, że w niektórych przypadkach, jeśli tymczasowe miejsce przechowywania było wykorzystywane do modelowania danych, odniesienie do sesji w Modelu byłoby do przyjęcia. –

2

Kontroler shd wykona sprawdzenie, czy sesja pogodowa istnieje, czy nie, przed użyciem modelu, który korzysta z tej sesji wewnątrz niego.

+0

Widziałem to, ale pojawia się problem modeli posiadających inne modele. Co się stanie, jeśli model używany w innym modelu używa zmiennej sesji? Wygląda na to, że pisze się dużo kodu w kontrolerze, aby zarządzać tym, co w rzeczywistości powinno znajdować się w kontrolerze. Więcej myślenia na głos niż nie zgadzać się z tobą. – timpone

+0

@timpone przy przekazywaniu sesji jako parametru do modelu nadal musisz wykonać wszystkie kontrole w kontrolerze. Jak sama nazwa mówi, zadaniem kontrolera jest zapewnienie kontroli nad logiką, która mieści się w modelach. –

+0

+1 Zgadzam się, nie musisz sprawdzać sesji w modelach, to jest zadanie wtyczek. Prawdopodobnie brakuje ci czegoś w swojej architekturze. W przeciwnym razie jest to zadanie Zend_Registry. –

0

Co jest przechowywane w zmiennych sesji? Jeśli jest po prostu "zalogowany? T/N ', to prawdopodobnie nie muszą być częścią warstwy modelu. Jeśli jednak jest to bardziej skomplikowane, prawdopodobnie są one nierozerwalnie związane z twoim modelem biznesowym i powinny być traktowane jako takie.

Przykłady na dole dokumentacji testu Zend pokazują, jak przetestować pełny MVC za pomocą funkcji logowania. Prawdopodobnie możesz zrobić to samo podczas testowania modeli?

+0

thx za wskazanie tego; jak wszystko, co myślę, że to zależy. W złożonej aplikacji wygląda na przepis na katastrofę. Ogólnie rzecz biorąc, uważam, że zawsze chcę wykonać pewne przetwarzanie danych w celu ich wyszukania, a faktyczne zmienne sesji to komplikują. Czy można to zrobić? tak Czy należy to zrobić? niepewny – timpone

0

Nie, nie powinno. Typ przechowywania powinien być inny niż logika biznesowa. Na przykład:

Mam jedną prostą wtyczkę, która przeprowadza kontrolę dostępu i umieszcza obiekt użytkownika w rejestrze. Tak więc zamiast sesji dostępu model ma dostęp do rejestru, który jest dobrze zdefiniowany.

$User = Zend_Registry::get('User'); // User model object

Z teoretycznego punktu widzenia, wszystko powinno być dostępne poprzez mappers danych. W przyszłości, jeśli zmienisz z pamięci sesji na coś innego, musisz zaktualizować ją tylko w jednym miejscu. Twoje modele nie muszą wiedzieć skąd pochodzą dane.

Jeśli używasz więcej niż jednej ścieżki, aby uzyskać dane, prawdopodobnie spowoduje to pewne problemy, gdy aplikacja stanie się duża.

Propozycja podejścia do OOP i systemów warstwowych polega na tworzeniu wyspecjalizowanych obiektów i warstw oraz utrzymaniu prostoty zapobiegając rozprzestrzenianiu się określonych działań w całym kodzie.

Ale znowu nie trzeba tego zmieniać, chyba że widzisz zalety. Należy pamiętać, że czasami refaktoryzacja jest bardziej skuteczna niż próba przewidywania wszystkiego.

Powiązane problemy