Sterownik a model - Potrzebuję wyjaśnienia

Question

Jestem na początku mojego "uczenia się MVC". Zasadniczo nie mam dużych problemów z programowaniem obiektowym, jednak istnieje jeden aspekt techniczny, który wymaga wyjaśnienia. Wygląda na to, że moja teoria nie jest wystarczająco dobra.

Obecnie używam KohanaPHP ramy, wersja 3.

przykładowej sytuacji: Mam stronę internetową, gdzie użytkownik może przesłać artykuł.

Więc mam następującą strukturę:

classes/ 
    /controllers/ 
     article.php 
    /models/ 
     articles.php 

tej pory tak dobrze. Nie mam problemów z modelami, które rozszerzają Kohana_Model, ale nie jestem pewien, czy używam prawidłowych modeli, które używają ORM.

Zasadniczo przy używaniu modeli rozszerzających Kohana_Model umieszczam wszystkie operacje logiczne w modelu. Czy powinienem zrobić to samo dla modeli używających ORM? W wielu przykładach w sieci widziałem kontrolerów, którzy wykonywali logiczne operacje na danych wejściowych/danych z bazy danych, co moim zdaniem jest nieprawidłowe.

Załóżmy, że potrzebuję uzyskać kilka wierszy z bazy danych, więc tworzę właściwą metodę w modelu i zwracam obiekt. Myślę, że to prawda, prawda?

Zasadniczo wszystkie operacje na danych wejściowych użytkownika/danych (wybierz z db, wstaw do db, sprawdzanie poprawności) Wstawiam modele. W ten sposób rozumiem wzór projektu MVC. Modele powinny dbać o wszystkie "mechaniczne" operacje, a kontroler jest tylko "pomostem" pomiędzy modelami/widokami i jest "frontowym" silnikiem.

Czy to właściwe podejście?

Wiem, że to może być głupie pytanie dla bardziej zaawansowanych użytkowników, ale chcę się uczyć tylko dobrych praktyk. Jeśli ktokolwiek mógłby dostarczyć pewnych wyjaśnień, będę zachwycony.

Answer 1

w krótkich słowach, model wykonuje wszystkie operacje na danych (zarówno przychodzące, wychodzące, bazy danych, pliki ... dane), a twój widok powinien zająć się wyświetlaniem danych. Kontroler powinien wywołać niezbędne metody modelowania, aby przygotować dane do przekazania do widoku. Kontroler nie powinien wprowadzać żadnych zmian w danych, ale powinien je przetestować, aby odpowiednio wykonać niezbędne czynności.

Mam nadzieję, że jasno to wyjaśniłem, daj mi znać, jeśli to nie wyjaśni ci wszystkiego.

Answer 2

Nie pracowałem z KohanaPHP, ale wygląda to na "inspirowane ramiakami" ramy. W świecie szyn uważa się za najlepszą praktykę stosowanie chudych kontrolerów i grubych modeli.

niektóre tła można znaleźć w tym starym artykule Jamis złotówki http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model lub w tej jednej sprawie CakePHP http://gluei.com/blog/view/cakephp-best-practices-fat-models-and-skinny-controllers

Answer 3

Pomysł oddzielenia logiki od danych jest taki, że dane nie zawierają logiki, więc w modelach powinno się naprawdę tylko oczyszczać dane.

Weźmy ten przykład:

public class Articles extends MasterModelLayer 
{ 
    public function create($title,$text,$user_id = false) 
    { 
     if(!$user_id) 
     { 
      $user_id = get_guest_id(); 
     } 
     //Insert 
    } 
} 

wydaje się uzasadniony logikę w modelach, ale od teraz Twoja aplikacja musi być w stanie umożliwić gościom pisać artykuły, lub jego wadliwa i trzeba edytować modele, które wtedy podłogowe inne aplikacje/obszary witryny

Weź ten scenariusz:

masz 2 miejsca

• ComputerArticles.com
• CookingArticles.com

Teraz te 2 domeny wskazują na tym samym serwerze, ale w oddzielnym wniosku kohona być nie umieszczanie jakiejkolwiek logiki domeny w ramach swoich modeli w stanie wykorzystać swoje dokładne przykładowe modele we wszystkich twoich domenach.

swoje metody model powinien wyglądać tak:

public class Articles extends MasterModelLayer 
{ 
    public function create($title,$text,$user_id) 
    { 
     $this->compile("articles",array($title,$text,$user_id))->insert(); 
    } 
} 

I w twoich sterowników należy umieścić całą swoją logikę jak logika zależy od domeny.

Pomyśl o swoich modelach jako o interfejsie API, w którym masz wiele witryn używających tego samego interfejsu API, ale pod inną logiką.

Mam nadzieję, że to pomoże.

Answer 4

Oto podstawowe definicje laika terminów - Widoki: Ekrany prezentowane użytkownikom Kontroler: silnik/framework, który przyjmuje żądania, określa, kto je obsługuje i przekazuje je odpowiednio. Model: Zasadniczo informuje o tym, jaki ekran ma być wyświetlany po wykonaniu tej czynności. Na tym ekranie wykonywane są czynności. Pomyśl o tym jako o (ukierunkowanym) wykresie. Krawędzie wychodzące z węzła to akcje, a węzły, z którymi się łączą, to kolejne ekrany oparte na tych akcjach.

Tak więc model w zasadzie zawiera czynności, które użytkownik wykonuje na ekranach i ich modułach obsługi. Sterownik po prostu wywołuje odpowiedni moduł obsługi akcji dla określonego działania użytkownika, a moduł obsługi akcji jest odpowiedzialny za zrobienie czegoś sensownego z przychodzącym żądaniem.

Teraz twoje pytanie. Gdzie idzie logika biznesowa? Cóż, to jest handler akcji. Lub jest wyodrębniany gdzieś, jak ludzie nazywają - warstwa biznesowa. Ale tak czy inaczej jest on wyzwalany od samych agentów akcji.

Logicznie rzecz biorąc, logika biznesowa jest częścią działań, które same stanowią część Modelu. Ma to sens, jeśli myślisz tak: kontroler obsługuje interakcję użytkownika i prezentuje widoki na podstawie modelu (działania + biznes).

** Poprawiono literówki.