Dlaczego MVC jest tak popularny?

Question

Pierwotnie zamierzałem sprawić, by było to dłuższe pytanie, ale czuję, że im krótsze to zrobię, tym lepiej zrozumiesz, co mam na myśli.

• Wzór architektoniczny MVC ma 3 zależności. Widok zależy od modelu. Kontroler zależy od widoku i modelu. Model jest niezależny.

• Wzorzec architektoniczny Warstwy określa zależności N-1, gdzie N to liczba warstw.

Biorąc pod uwagę trzy warstwy: model, widok i kontroler, istnieją tylko 2 zależności, w przeciwieństwie do 3 z tradycyjnym MVC. Struktura wygląda następująco:

View ---> Controller ---> Model 

[zobacz zależy od kontrolera, kontroler zależy od modelu]

Wydaje mi się, że ten styl realizuje te same cele i produkuje luźniejsze sprzęgła. Dlaczego ten styl nie jest bardziej powszechny? Czy naprawdę osiąga te same cele?

Edytuj: Nie ASP.NET MVC, tylko wzór.

W odniesieniu do postu griegs męska:

• ile szyderczy, warstwy nadal pozwala korzystać z poleceń procesora wzór do symulowania kliknięcia przycisków, jak również wszelkich innych wachlarz imprez.
• Zmiany w interfejsie użytkownika są nadal bardzo proste, a może nawet łatwiejsze. W MVC kontroler i widok mają tendencję do łączenia się ze sobą. Warstwy tworzą ścisłą separację. Obie warstwy są czarnymi skrzynkami, które mogą różnić się niezależnie pod względem implementacji.
• Kontroler ma 0 zależności w widoku. Widok można zapisać, a czas można jeszcze zaoszczędzić przy luźnym sprzężeniu.

Answer 1

I nie dostał z powrotem do tego od dłuższego czasu, głównie dlatego, że wciąż myśli. Byłem niezadowolony z otrzymanych odpowiedzi, tak naprawdę nie odpowiedziałem na moje pytanie.

Niedawno profesor poprowadził mnie we właściwym kierunku. Zasadniczo powiedział mi to: Warstwy, które dzielą Model, Widok i Kontroler to MVC. W wektorze waniliowym MVC zależność między widokiem do modelu często nie jest używana, a Ty skutecznie kończysz warstwami. Pomysł jest taki sam, nazwa jest po prostu słaba.

Answer 2

Ponieważ odłączyć interfejs od kontrolera ułatwia wprowadzanie zmian.

Weź również pod uwagę scenariusz, od którego należy zacząć projekt, ale grafika nie będzie gotowa na tygodnie lub miesiące. Czy czekasz, czy piszesz cały kod wymagany dla stron i po prostu podłączasz widok do kontrolera.

Przynajmniej to zrobiliśmy i zaoszczędziliśmy miesiące.

Ułatwiliśmy też wprowadzanie zmian w interfejsie użytkownika, ponieważ na naszych stronach aspx nie było żadnego kodu, który coś zrobił.

Nasze testy były również lepiej jak mogliśmy makiety nic w tym kliknięcia przycisków itp

A jeśli mówisz ramach asp.net-MVC, nie ma kodu w plikach aspx i bez stanu wyświetlania itp.

Answer 3

W prawidłowym MVC kontroler nie zależy od widoku afaik. A może nie rozumiem tego poprawnie.

Model definiuje dane.

Widok określa wygląd wydruku.

A kontroler jest tłumaczem z gramatyki zrozumiałej dla modelu do gramatyki postrzeganej jako rozumianej.

W zasadzie kontroler jest niezależny. Widok jest niezależny. A model jest niezależny.

Tak? Nie?

Answer 4

Moim zdaniem lepiej wypróbuj to w swoim programie, możesz użyć ruby ​​na szynach lub codeigniter (dla php), te świetne ramy mogą być pomocne w zrozumieniu MVC.

Answer 5

Będę odważny i spróbuję wyjaśnić, dlaczego twoja metoda się nie przyłączyła.

Wzór MVC zasadniczo wymaga warstw widoku i modelu do uzgodnienia interfejsu API. Ponieważ jeden służy drugiemu i nie ma zależności wewnątrz kodu, to kontroler zachowuje się w sposób ogólny, wystarczy, że weźmie określoną strukturę w warstwie widoku i wywoła pasujące API na warstwie modelu.

Należy zauważyć, że uzgodnienie interfejsu API między widokiem a modelem nie jest tak naprawdę wielką rzeczą, że tak się stanie. A to, co dostajesz, to dobra separacja pomiędzy front-endowym rozwojem.

W proponowanym rozwiązaniu po stronie kontrolera wymagane jest wiele ulepszeń. Kontroler będzie musiał zrozumieć wszystkie elementy w widoku i zmapować je do konkretnych połączeń wymaganych na warstwie modelu. Ponieważ kontroler jest pojedynczym punktem dostępowym łączącym wiele widoków z wieloma modelami, może szybko wymknąć się spod kontroli i ostatecznie stanie się niezrozumiałym modułem kontrolera.

Spójrz na kilka przykładów Struts2 aby zobaczyć, co mam na myśli ...

Answer 6

Chyba rozumiejąc swój punkt:

Tak można dokonać View zależy tylko od kontrolera tylko poprzez kontroler przekształć (używając PHP jako przykładu) obiekty modelu na obiekty inne niż modele, takie jak proste tablice.

Jak już wiemy, przeprowadzenie tej transformacji może wymagać więcej wysiłku, niż jest to warte, jeśli oddzielenie nie jest faktycznie potrzebne. Jeśli widok korzysta z obiektów modelu, ma tę zależność. Można to jednak nieco złagodzić, ponieważ widok zależy wyłącznie od kontrolera w zakresie wymaganych danych wejściowych, którymi mogą być obiekty modelu.

Szkielet Symfony PHP promuje ten styl chudego kontrolowania tasowania między modelem a widokiem. Nadal możesz wywoływać warstwę Modelu, aby pobierać obiekty z warstwy Widok, ale jest ona silnie przeciwwskazana w przypadku problemów z łączeniem, które wywołujesz. W widoku można wywołać metodę include_component(), która w rzeczywistości wraca do kontrolera, jeśli chcesz przesłać zapytanie do Modelu.

Answer 7

Wybór wzorca prezentacji dla nowego lub korporacyjnego tworzenia stron internetowych na platformie Microsoft jest zniechęcającym zadaniem, moim zdaniem są tylko trzy; Zobacz model, model-widok-prezenter (MVP) lub ASP.NET MVC (pochodna Model2).

można przeczytać cały artykuł tutaj ASP.NET MVC Patterns

Answer 8

Chciałbym dodać jeszcze kilka rzeczy. Przede wszystkim z mojego punktu widzenia używamy modelu jako kontenera dla informacji, które chcemy przekazać i pokazać w widoku.Zazwyczaj metody działania do sterownika kończy się zdaniem powrotnej („VIEWNAME”, model) .Powierzchnia sam widok probabily zmieni layour przeciwko modelu

na widoku:

if (model.something == prawda) {

%>

somethign pokazać

<%

}

W tym poinf trudno jest znaleźć definicję modelu.

mogę powiedzieć (szczególnie na conext przedsiębiorstw) osoby są dwa „model”

nich jest model domeny/modelu podmiot lub jak chcesz to nazwać, że owija danych pochodzących z niższych warstw (bazy danych, itp.) oraz model widoku, który zawiera informacje, które chcemy pokazać, oraz wszelkie inne informacje potrzebne do ukrycia/pokazania części interfejsu

Sterownik steruje widokami i jest niezależny od widoku, ale nieco różni się od widoku model:

do kontrolera

Pulic ActionResult Index() {

....

if (model.BoolProperty == true) {

powrotu ("firstView);

}

inny

{

powrotu ("secondView");

}

}

Mam nadzieję, że to ma sens