Grube modele, chudy kontrolery i wzorce projektowe MVC

Question

Grube modele, chudy kontrolery i wzorce projektowe MVC

Właśnie przeczytałem wpis na blogu który wyjaśnia MVC analogią bankową. Mam kilka miesięcy doświadczenia w tworzeniu aplikacji internetowych z frameworkiem MVC( CakePHP), więc rozumiem podstawy, ale zacząłem widzieć temat, który sprawił, że myślałem, że biorę błędne podejście do tego, gdzie umieszczam moją logikę: {]}

Grube modelki, chudy kontroler
Zachowaj jak najwięcej logiki biznesowej w modelach

W mojej aplikacji modelki są anorektyczki, a kontrolerzy otyli. Mam Cała logika biznesowa w kontrolerach i nic poza asocjacjami i regułami walidacji w modelach.

Skanując przez moje Kontrolery, mogę teraz zidentyfikować wiele logiki, które prawdopodobnie powinny iść w modelu:

aplikacja ma listy, które zawierają przedmioty, a przedmioty mogą być uszeregowane. Logika sortowania, która umieszcza listę w kolejności rankingowej, znajduje się w kontrolerze.
podobnie elementy (Model elementu) mają również obrazy (Model obrazu). Każdy element może mieć domyślny obraz (oznaczony przez image_id w tabeli items). Gdy element jest wyświetlany z jego obrazami, najpierw powinien pojawić się domyślny obraz. Mam logikę, która robi to w kontrolerze.
gdy lista jest wyświetlana, powiązane listy są wyświetlane na pasku bocznym. Logika określająca, które listy są powiązane, znajduje się w kontrolerze.

A teraz moje pytania:

z przykładami, które podałem powyżej, czy jestem na dobrej drodze w myśleniu, że są to przykłady logiki obecnie w kontroler, który należy do modelu?
Jakie są inne obszary logiki, wspólne dla aplikacji internetowych, które powinny znaleźć się w modelach?
jestem pewien, że zidentyfikowanie tego problemu i zmiana mojego wzorca projektowego to połowa sukcesu, ale nawet gdybym zdecydował się na powyższe przykłady i spróbował przenieść tę logikę na model, nie wiedziałbym od czego zacząć. Czy ktoś może wskazać mi właściwy kierunek, zamieszczając tutaj jakiś kod lub łącząc się z dobrymi zasobami edukacyjnymi? CakePHP konkretna pomoc będzie świetnie, ale jestem pewien, że cokolwiek MVC wystarczy.

74

model-view-controller model controller cakephp

Author: Ciaran, 2009-01-22

Source

2 answers

Używam przynajmniej tych dwóch 'testów', aby sprawdzić, czy moja logika jest na właściwym miejscu:

1) jeśli napiszę unittest, łatwo jest stworzyć tylko jeden "prawdziwy" obiekt do wykonania testu (=obiekt, którego używasz w produkcji) i nie zawierać wielu innych, z wyjątkiem może niektórych obiektów wartości. Potrzeba zarówno rzeczywistego obiektu modelowego, jak i rzeczywistego obiektu kontrolera do wykonania testu może być sygnałem, którego potrzebujesz, aby przenieść funkcjonalność.

2) zadaj sobie pytanie: co jeśli dodam innym sposobem korzystania z tych klas, czy muszę powielać funkcjonalność w sposób, który jest prawie kopiuj-wklej? ... To również prawdopodobnie dobry powód, aby przenieść tę funkcjonalność.

Również ciekawe: http://www.martinfowler.com/bliki/AnemicDomainModel.html

19

Author: Simon Groenewolt,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-21 22:33:17

score 55 · Accepted Answer

Trochę trudno jest dać ci" właściwe " odpowiedzi, ponieważ niektóre z nich dotyczą specyfiki frameworka (niezależnie od tych, z którymi pracujesz).

Przynajmniej pod względem CakePHP:

Tak
Wszystko, co dotyczy danych lub manipulacji danymi, powinno być w modelu. Jeśli chodzi o CakePHP co z prostą metodą find ()? ... Jeśli istnieje szansa, że zrobi coś "specjalnego" (tj. przypomni określony zbiór "warunku"), który może trzeba gdzieś indziej, to dobry pretekst, aby owinąć się w metodę modelki.
Niestety nigdy nie ma łatwej odpowiedzi, a refaktoryzacja kodu jest procesem naturalnym. Czasami po prostu budzisz go: "Święty makaron... to powinno być w modelu!"(no może ty tego nie robisz, ale ja mam :))