Widziałem napisany kod, w którym prawie cały kod związany z trasą jest przekazywany do modelu. Widziałem również kod, w którym cała trwałość bazy danych jest obsługiwana przez model, ale przetwarzanie non-DB jest obsługiwane przez kontroler.w MVC, gdzie narysujesz linię między kontrolerem a modelem?
Jakie jest lepsze podejście?
Linia między kontrolerem a modelem jest całkiem jasna.
Model to serce Twojej aplikacji. Zawiera logikę biznesową/domenową wymaganą do rozwiązania problemu, dla którego napisano twoją aplikację. Model zazwyczaj składa się z kilku warstw, np. uporczywość, usługi, domena itd. Powszechnym błędnym przekonaniem jest to, że Model jest po prostu bazą danych, tak samo jak powszechnym błędnym przekonaniem, że baza danych powinna być ActiveRecord.
Kontroler (i widok) są częścią warstwy prezentacji. Wyłączną odpowiedzialnością kontrolera jest otrzymywanie danych wejściowych od użytkownika skierowanych do aplikacji i przekazywanie ich do odpowiednich części w modelu. Nic więcej. Nie powinien obsługiwać złożonego przepływu aplikacji lub kodu twojej domeny problemowej. You want controllers to be skinny and models fat with logic. Model nie powinien wiedzieć o C lub V i powinna być w stanie zamienić się V i C dla innej warstwy prezentacji bez konieczności dotykania Twój M.
Zobacz MVC Excerpt in Patterns of Enterprise Application Architecture
Stoję (a raczej siadam na krześle przy biurku ...). +1 – BoltClock
możliwe dup? http://stackoverflow.com/questions/467113/fat-models-skinny-controllers-and-the-mvc-design-pattern –