Wzór projektu MVC. Jak View to pasuje?

Question

Mam pytania dotyczące wzorca projektowego widoku modelu. Rozumiem, że model zawiera dane. Rozumiem również, że kontroler (kontrolery widoku) implementuje logikę aplikacji. Na przykład, jeśli kółko UIPicker wybierze wiersz 4, kontroler widoku może poprosić Model o czwarty obiekt przechowywany w tablicy Modelu. Mam problemy ze zrozumieniem, gdy pasują do nich "Widoki". Sądzę, że ten plik ze stalówką/scenorem zostałby sklasyfikowany jako "Widok". Jednak każdy widok wymaga podłączenia kontrolera widoku w celu podłączenia wszystkich gniazd do widoku. Jak mam zachować separację widoku i kontrolera widoku? Czy powinienem podłączyć wszystkie gniazda do "View Class", a następnie w moim kontrolerze View, odwołując się do mojej klasy "View" podczas implementacji logiki tych punktów? Może po prostu potrzebuję przykładu gdzie View i kontroler widoku obsługują różne zadania. W przeciwnym razie dodatkowa klasa "Widok" nie wydaje się mieć sensu. Czy widok MVC odnosi się do klasy widoku? Jak lub dlaczego chciałbym, aby ta klasa widoku była oddzielona od mojej klasy kontrolera widoku?

Answer 1

Zadaniem widoku jest wyświetlanie danych i raportowanie zdarzeń.

Zadaniem sterownika jest koordynacja komunikacji między widokami a modelami.

Zadaniem danych jest przechowywanie danych, a także zapewnienie logiki biznesowej wokół tych danych.

Pytałeś:

mam problemy ze zrozumieniem były „Widoki” pasować

w twojej przykład UIPickerView jest widok..

W systemie iOS/OSX kontroler widoku to tylko kontroler MVC. Tak się składa, że ​​kontroler widoku zawiera również pusty kontener widoku, do którego można dodać wszystkie inne widoki. Ale wciąż istnieje wyraźne oddzielenie MVC w systemie iOS/OSX.

Wszystkie klasy, takie jak UIButton, UIPickerView, UITableView itd. Reprezentują widok. Zadaniem kontrolera widoku jest dostarczanie tych widoków danych z modeli danych, a także reagowanie na zdarzenia z tych widoków, co daje szansę na aktualizację innych widoków i modeli danych.

Ty stwierdził również:

Jednak każdy widok wymaga, aby View Controller być podłączony do drut aż wszystkie wyloty do widoku. Jak mam zachować separację widoku i kontrolera widoku?

Są oddzielne. Jeśli dodasz UITableView, będzie to osobny widok. Połącz go z klasą, aby klasa mogła implementować źródło danych i delegować metody. Ta klasa jest klasą kontrolera. Często ta klasa kontrolerów jest kontrolerem widoku, ale nie musi. Można pisać wszystkie niestandardowe klasy widoku, które są niezależne od dowolnego kontrolera widoku (lub ogólnego kontrolera). Ale ostatecznie ta klasa widoku musi zostać podłączona do klasy kontrolera [view], aby dane i zdarzenia mogły być poprawnie przetwarzane.

Pytałeś:

Jak i dlaczego miałbym chcieć mieć ten pogląd klasy oddzielony od moim zdaniem klasa kontrolera?

Spójrz na UITableViewController. Jest to wyraźny przykład oddzielenia, ale jest dostarczany w dość zgrabnym opakowaniu. Właściwie masz oddzielną klasę UITableView, która jest widokiem. Ten widok jest odpowiedzialny za renderowanie widoku i zbieranie interakcji użytkownika. Jest to rzeczywisty kontroler widoku tabeli, który dostarcza dane do widoku i obsługuje zdarzenia użytkownika z widoku. Możesz dodać widoki UITableView do dowolnego widoku Jest to komponent widoku do wielokrotnego użytku. Każdy kontroler podłączony do widoku tabeli może dostarczać dowolne odpowiednie dane i odpowiednio obsługiwać interakcje użytkownika.

Answer 2

Dobra, postaram się trochę uporządkować.

Wzór nosi nazwę Sterownik widoku modelu, dzięki czemu wyraźnie oddziela model, widok i kontroler. Jak słusznie zauważyłeś, ViewController układa wszystko razem (z widoku i kontrolera :) i faktycznie ViewController łamie silny wzorzec MVC. Dobrą wiadomością jest to, że nie musisz oddzielać widoku od kontrolera, jeśli korzystasz z ViewController (zgadnij, dlaczego tak się nazywa?).

Teraz moja Nooby wyjaśnienie dlaczego projekt jest, co to jest:

Kiedy mocno oddzielić View i Controller w zasadzie zdobyć punkty kredytowe dla dobrego projektu. Jednak, jak się okazuje, nie są one tak rozdzielone, jak byśmy chcieli. Różne reprezentacje GUI zwykle wymagają innej implementacji widoku, jak również adaptacji kontrolera, który steruje przekazywaniem Modelu do GUI, np. wyświetlanie zwykłego tekstu na konsoli i rysowanie na mapie bitowej. W pierwszym przypadku kontroler przekazałby ciąg znaków do renderowanego widoku, w drugim zaś musiałby ustawić pewne współrzędne, aby tekst był renderowany we właściwe miejsce. W związku z tym twój kontroler będzie się często zmieniać.

Idealnym rozwiązaniem byłoby zaimplementowanie modelu i kontrolera, a po prostu udostępnienie widoków dla wszystkiego, co ktokolwiek może zobaczyć w rzeczywistości. Jednak w rzeczywistych sytuacjach kontroler najprawdopodobniej dostosuje się do widoku, pozostawiając sam model. Dlatego decyzja projektowa, aby połączyć widok i kontroler z ViewControllerem, który zawiera określony widok i wie, jak go używać, jest rozsądnym rozwiązaniem.

Answer 3

Cóż, aby odpowiedzieć na twoje pytanie zepsujmy MVC - Model, Widok, Kontroler. Co jest gdzie?

Typ Model jest zwykle uważany za warstwę "zrób coś". To zawiera logikę biznesową i logikę danych. Twój model powinien być FAT, a nie SKINNY, co oznacza, że ​​powinieneś mieć dużo swojego kodu w Modelu.

Sterownik Sterownik, uważam za warstwę "odpowiedzi". Tutaj decydujesz, co powrócić do użytkownika, niezależnie od tego, czy jest to Widok, czy inny rodzaj odpowiedzi, na przykład JSON (szczególnie przydatny w odpowiedziach RESTful). Możesz również użyć modelu, ale nie powinieneś budować zbyt dużej logiki w samym kontrolerze. Powinieneś mieć kontroler SKINNY.

Znaczek ten jest w dużej mierze znacznikiem strony - kod HTML oraz inne znaczniki umożliwiające uzyskanie dostępu do modelu - zależy to od używanej struktury. Moje doświadczenie jest z MVC .NET, więc pójdę z tym.Zmieszany z kodem HTML uzyskujesz dostęp do elementów modelu. Nie powinno być żadnych realnych logika w widoku, ale można zrobić rzeczy jak (z użyciem składni Razor)

<div>@foreach person in Model.Users{ 
    <p>@person.FullName</p> 
} 
</div> 

Więc widać, że widok może mieć jakąś „logikę wyświetlania” (jak, pętlę nad ludźmi i zdobądź FullName), ale to wszystko, co naprawdę powinno tam być.

Oto krótki pokaz slajdów, który tłumaczy się więcej o MVC, w tym dlaczego początkowe wyjaśnienie „model posiada dane, Kontroler posiada logikę” w rzeczywistości nie jest prawdą: http://www.slideshare.net/damiansromek/thin-controllers-fat-models-proper-code-structure-for-mvc

MVC Pattern Design nie obejmuje wszystko, co nazywa się "ViewController", pochodzi z innego miejsca.

Answer 4

W rzeczywistości to, co rozumiesz, jest całkowicie błędne.

Podstawową zasadą wzornictwa MVC jest Separation of Concerns. Oddzielasz warstwę modelu od warstwy prezentacji i (w warstwie prezentacji) oddzielasz widoki od kontrolera.

Każdy tam pars mają różną odpowiedzialność:

• modelu warstwa zawiera wszystkie logiki biznesowej. Dotyczy to interakcji z pamięcią masową, logiką domeny i logiką aplikacji.
• Widok odpowiada za logikę interfejsu użytkownika. W kontekście sieci oznacza to, że widok zajmuje się tworzeniem odpowiedzi dla użytkownika, który jest elementem, który pobiera dane wejściowe użytkownika i na tej podstawie zmienia stan warstwy modelu i bieżącego widoku.

---

Istnieje wiele nieporozumieniem o MVC, że ludzie mają tendencję do utrwalenia. Na przykład:

1. Niektórzy będą nalegać, że poglądy są głupie szablonów. Oni nie są.

   Widoki we wzorcu projektu MVC są w pełni funkcjonalną instancją, która może lub nie może używać wielu szablonów do generowania odpowiedzi.

2. Nie ma "modeli". Model to warstwa, która składa się z wielu różnych grup klas, z których każda ma określone zadanie. Tak samo jak nie ma obiektów "prezentacji" dla warstwy prezentacji. Kontrolery nie wysyłają danych z warstwy modelu do widoków. Kontroler zmienia tylko stan innych części triady. Instancje widoku same żądają tego, czego potrzebują od warstwy modelu.