Ukrywanie metod modelu przed widokiem Opcje

[coolos]

Witam,

mam pytanie w jaki sposób ukryć metody modelu przed widokiem? Chciałbym aby z poziomu akcji możliwe było wywołanie:

[PHP] pobierz, plaintext 
$news->add_news($id);
[PHP] pobierz, plaintext 

lecz żeby niemozliwe było to w widoku. Chciałbym aby widok, pobierał dane tylko z getterów.

Pozdrawiam

[Orzeszekk]

uzyj smarty jako widoku

albo jesli koniecznie chcesz miec wlasny framework php, to wysyłaj paczkę danych z kontrolera (tzw viewModel), do widoku, zamiast wysylac twoj domain model.

niech kontroler uruchomi domain model (logike biznesowa), pobierze z niego potrzebne dane, ulepi z niego viewmodel w postaci klasy lub tablicy asocjacyjnej i tą paczke wysle do widoku w celu jej wyswietlenia. W ten sposob bedziesz mial zapewnione ze widok będzie "głupi" tj nie bedzie zawieral logiki.

robienie viewModelu to dobry wzorzec, dzieki temu mozesz podmienic klasy logiki bez modyfikowania widoków. Nie wiem jak pehapowcy, w asp.net mvc to praktyka zalecana.

Ten post edytował Orzeszekk 13.06.2012, 16:01:31

[coolos]

uzyj smarty jako widoku

Szablon a Widok to różnica (IMG:style_emoticons/default/wink.gif) .

[PHP] pobierz, plaintext 
albo jesli koniecznie chcesz miec wlasny framework php, to wysyłaj paczkę danych z kontrolera (tzw viewModel), do widoku, zamiast wysylac twoj domain model.
 
niech kontroler uruchomi domain model (logike biznesowa), pobierze z niego potrzebne dane, ulepi z niego viewmodel w postaci klasy lub tablicy asocjacyjnej i tą paczke wysle do widoku w celu jej wyswietlenia. W ten sposob bedziesz mial zapewnione ze widok będzie "głupi" tj nie bedzie zawieral logiki.
 
robienie viewModelu to dobry wzorzec, dzieki temu mozesz podmienic klasy logiki bez modyfikowania widoków. Nie wiem jak pehapowcy, w asp.net mvc to praktyka zalecana.
[PHP] pobierz, plaintext 

Z pewnością efekt finalny zostałby osiągnięty przy takim podejściu. Z tym że tworzenie "viewModel" jak to nazwałeś to nic inego jak wspomniany post wyżej przezemnie antywzorzec projektowy "anemiczny model dziedziny". Przesyłanie tablic asocyjacyjnych również nie uważam za rozwiązanie, to że tworzy się jakieś obiekty i pobiera z nich dane w postaci tablic nie czyni aplikacji obiektowej (są to jedynie procedury poupychane w klasach).

Szukam jakiegoś innego sposobu na ukrycie metod z logiką biznesową przed widokiem.

@coolos: Prawdę powiedziawszy ciężko tutaj powiedzieć czy to będzie poprawne czy nie bo nie znamy Twojego przypadku, ale generalnie używanie DTO nie jest czymś złym. Jedyne co można z całą pewnością powiedzieć to to, że obiekt posiadający methody addNews() i, jak się domyślam, coś w stylu getRecentNews(), getNewsByAuthor() nie powinien w ogóle istnieć (powinny to być osobne obiekty).

Przynam szczerze że korzystałem jak do tej pory z DTO i było ok.

Miałem np. klase news_model oraz news_model_manager, manger manipulował danymi dodając i pobierając newsy jako obiekty news_model.

Z tym że ostatnio naczytałem się że ogólnie takie podejście nie jest ok, jeżeli chodzi o programowanie obiektowe i szukam innego sposobu.


Szukam jakiegoś pomysłu na realizacje modelu2 z tego artykułu.

Ten post edytował coolos 13.06.2012, 16:25:21