Muszę wyjaśnić MVC nie-programistom. Mianowicie dla kierowników innych działów, w kontekście raportu z postępów. Jedną z rzeczy, które robię, jest zmiana naszej bazy kodu w kierunku separacji MVC.

Jaka może być separacja MVC? Dlaczego jest to konieczne, mogą zapytać?

Po przeczytaniu dość technicznej odpowiedzi takiej: Co to jest MVC, naprawdę? , Nie jestem w pełni usatysfakcjonowany, ponieważ będę rozmawiał z programistami. Mogą kiwnąć głową, ale prawdopodobnie nie zrozumieją, co to jest i dlaczego jest potrzebne.

W rzeczywistości nie do końca rozumiem, czym jest MVC oprócz „rozdzielenia problemów, obowiązków, funkcji, klas, bloków, zadań, rzeczy, aby poprawić elastyczność wprowadzania zmian w oprogramowaniu”. Oddzielanie bazy danych od widoku i widoku od logiki biznesowej za pomocą technik takich jak narzędzia i techniki DI i OO uważam za separację MVC.

Więc kiedy następnym razem wyjaśnisz MVC nieprogramiści, który ma doświadczenie w sprzedaży i księgowości, co byś im powiedział?

Nie wyjaśniasz MVC.

Wyjaśnisz, że jest to restrukturyzacja bazy kodu.

Restrukturyzacja, która upraszcza bazę kodu, a tym samym umożliwia programistom szybsze i lepsze zmiany w raportach błędów i żądaniach funkcji, przy mniejszej liczbie błędów.

Nie muszą znać szczegółów technicznych, tylko dlaczego zostało to zrobione, co zostało osiągnięte dzięki temu i jakie korzyści przynosi biznes.

Innymi słowy - mów do nich w ich języku.

Chociaż popieram sedno odpowiedzi Odeda , że powinieneś wyjaśniać projekty techniczne menedżerom biznesu „w ich języku”, mam jednak pewne wątpliwości, że „nie muszą znać szczegółów technicznych, tylko dlaczego tak się stało”.

Jeśli jesteś na spotkaniu dotyczącym przeglądu projektu lub inwestycji z szefami działów i deklarujesz „to właśnie robimy”, mogą chcieć zapytać „Umm ... dlaczego? Wydaje się, że to duża inwestycja czasu i energii. Czy możesz dać nam trochę więcej zrozumienia, co robisz i dlaczego? To wydaje się niezwykle rozsądne pytanie. Nie chcesz dać się złapać w pozycji „Cóż ... to skomplikowane”. lub „Nie, tak naprawdę nie potrafię tego wyjaśnić”. lub „Nie martw się tym”. Im wyższy poziom personelu, dla którego przeprowadzasz ocenę projektu, tym mniej prawdopodobne jest, że pozwolą, by „to tylko rzeczy, których nie potrafię dobrze wytłumaczyć”. Lepiej, jeśli możesz wejść co najmniej o jeden poziom głębiej, aby inni czuli się komfortowo, aby 1) wiesz, co

Miej więc szkic MVC w kieszeni na biodrze, gotowy do pracy. Coś jak:

„To trochę techniczne, ale ... MVC dzieli kod na modele (odpowiedzialne za podstawowe dane i logikę biznesową), widoki (które wyświetlają dane) i kontrolery (które obsługują interakcje użytkowników i aktualizacje). Jest to sprawdzona architektura -prawdopodobnie najbardziej udany „wzorzec projektowy w inżynierii oprogramowania”. Wiem, że może to wydawać się „tylko hydrauliką”, ale aby obsłużyć wszystkie nadchodzące żądania, potrzebujemy silniejszych podstaw. To pozwoli nam zbudować nowe podstawy funkcje i szybsze rozwiązywanie problemów ”.

Nawet jeśli nie w pełni rozumieją MVC na końcu i nawet jeśli musiałeś zbytnio uprościć, aby było zrozumiałe („rozbić jajka, aby zrobić omlet”), zakładam się, że wygodniej będzie ci przygotuj wyjaśnienie niż powiedzieć „nie potrafię tego wyjaśnić” lub „nie masz kwalifikacji, aby je zrozumieć” dla kierowników wyższego szczebla.

w celu zwiększenia elastyczności wprowadzania zmian w oprogramowaniu

Menedżerowie są zainteresowani wynikiem końcowym. Im mniej techniczne, tym mniej prawdopodobne, że martwią się o to, jak się tam dostać. MVC jest bardzo popularne, popularne i sprawdzone.

Gdy w przyszłości będą składane wnioski o zmianę, możesz poinformować kierownictwo, że można je ułatwić i przyspieszyć. Każdy lubi to słyszeć.

Jest to powszechna strategia, więc zatrudnianie nowych programistów nie powinno stanowić problemu. W rzeczywistości możesz przyciągnąć lepszych programistów, którzy są silnymi zwolennikami.

Wszystko to będzie bardzo trudne, jeśli w tym konkretnym projekcie jest wiele naglących problemów. Mogą nie chcieć zrobić kroku wstecz, abyś mógł zrobić dwa kroki do przodu. Rozwiązaniem może być poczekanie lub wdrożenie w mniejszych częściach.

• Model - przewody / prąd
• Widok - oprawa oświetleniowa
• Kontroler - włącznik światła

Stosunkowo łatwe do wyłączenia komponenty (oprawa oświetleniowa, włącznik / ściemniacz). Może nie tyle okablowanie, ale nadal można to zrobić bez wpływu na inne elementy. Każdy powinien być w stanie to sobie wyobrazić, nawet w marketingu / sprzedaży. (Wyczyść separację itp.)

Teraz powiedz swojemu szefowi / współpracownikom, że w naszej aplikacji / systemie przełącznik jest osadzony w oprawie oświetleniowej, a oprawa oświetleniowa jest owinięta drutem miedzianym. Teraz wyobraź sobie, że próbujesz zaktualizować oprawę oświetleniową, przełącznik lub przewód. Bardzo kosztowne, wpływ na inne komponenty jest bardzo wysoki i może być niebezpieczny bez zepsucia czegoś innego.

MVC stosuje wzorzec do podstawy kodu, który zamienia pomieszany (ale działający) bałagan w coś, w którym zmiany mogą następować szybciej i łatwiej przy mniejszej liczbie błędów.

Łatwym sposobem, aby zrozumieć MVC: model danych The view to okno na ekranie , a kontroler jest klej między nimi .

Najlepsza rubryka w historii: „Potrzebujemy modeli SMART, kontrolerów THIN i ​​widoków DUMB”

Podobnie jak w przypadku innych wzorców projektowych oprogramowania, MVC wyraża „ rdzeń rozwiązania ” problemu, umożliwiając jego dostosowanie do każdego systemu. Lepiej jest to postrzegać jako koncepcję, a nie konkretne wdrożenie. Istnieje wiele wdrożeń tej koncepcji.

Wszystkie warianty MVC wykorzystują ten sam podział komponentów, ale zwykle różnią się sposobem interakcji tych komponentów.

Dla tych, którzy nie są świadomi, MVC został pierwotnie opisany w formie wzoru do użycia z Smalltalk przez Trygve Reenskaug w 1979 roku . Jego artykuł został opublikowany pod tytułem „Programowanie aplikacji w Smalltalk-80: Jak korzystać z Model-View-Controller” i przygotował grunt pod większość przyszłych wdrożeń MVC.

W połowie zgadzam się z Odedem - nauczenie się, jak przekonać swoich nietechnicznych kolegów i menedżerów, że to, co robisz, jest ważne i przydatne, bez wyjaśnienia drobiazgowych szczegółów, jest konieczną umiejętnością, którą mądrze byś rozwinął.

Uważam jednak, że umiejętność wyjaśnienia skomplikowanych pojęć w prostych słowach w rzeczywistości pomaga w tym - jednym z problemów często spotykanych przez menedżerów nietechnicznych jest to, że ponieważ mają problemy ze zrozumieniem, co robią technicy, mają tendencję do nie ufaj im. Jest to po prostu ludzka natura: łatwiej jest uwierzyć, że coś, czego nie rozumiesz, jest bezużyteczne lub złe, niż polegać na nim. Dlatego, jeśli możesz sprawić, by koncepcje były łatwe do zrozumienia do woli, możesz z nich korzystać, kiedy będziesz ich potrzebować, a wraz z upływem czasu, twoi nietechniczni kierownicy dowiedzą się, że mogą je zrozumieć, jeśli zechcą - nie przekonasz się na nich - po prostu oszczędzasz im szczegółów dla własnego zdrowia psychicznego. Będą ci bardziej ufać.

Poza tym odpowiedzmy na pytanie:

Uważam za użyteczne stosowanie analogii zrozumiałych dla ludzi biznesu. W przypadku MVC opisuję to jako biznes.

• Modele są odpowiedzialne za logikę biznesową i dane - są to rzeczy, które definiują to, co robi program i szczegóły, jak to robi. Gdyby program był biznesem, modelami byłyby magazyny, fabryki, pracownicy i sprzęt kapitałowy. Byliby to również menedżerowie niższego poziomu, którzy dbają o przestrzeganie zasad i egzekwowanie zasad.
• Widoki są warstwą prezentacji - pokazują użytkownikom, co dzieje się w systemie i zapewniają środki do interakcji z programem. Gdyby nasz program był firmą, widoki przypominałyby podłogę salonu, stoisko sprzedaży na zjeździe handlowym lub przedstawicieli handlowych. Wyświetlają opcje, zapewniają przyjazne dla użytkownika informacje i opinie oraz odbierają zapytania z powrotem do firmy.
• Kontrolery są warstwą koordynacyjną - zapewniają, że informacje przekazywane są z modeli do widoków i odwrotnie, a wszystko działa razem, aby wykonać swoją pracę. Gdyby program był firmą, wówczas kontrolerami byłoby kierownictwo średniego i wyższego szczebla. Nie angażują się zbytnio w szczegóły, ale dbają o to, aby właściwi ludzie mieli odpowiednie narzędzia do wykonywania swojej pracy, i zatwierdzali lub odrzucali decyzje na wysokim szczeblu. Zapewniają ogólny kierunek, dzięki czemu wszystko może działać razem.

Korzyścią z wyjaśnienia tego za pomocą tej analogii jest to, że dobry menedżer zobaczy mądrość w rozdzielaniu problemów w ten sposób i może zdecydować, że powinny one być bardziej podobne do kontrolerów i nie będą zbytnio angażować się w szczegóły w przyszłości!

Mam nadzieję, że odpowie na „co” - „dlaczego” jest również łatwe dzięki tej analogii:

Wyobraź sobie idealną firmę, w której każdy dział odpowiada za jeden zestaw zadań i wie, że zawsze będzie miał potrzebne zasoby, nie martwiąc się o to, co robią inni. Przedstawiciel handlowy znajduje klienta, otrzymuje zamówienie, przekazuje je kierownictwu, który je zatwierdza, a następnie przesyła je do magazynu / produkcji / inżynierii w celu realizacji. Informacje zwrotne są bezpośrednie - nikt inny nie musi się angażować, chyba że wystąpi problem. To dobry projekt MVC - każda część ma zadanie i nie musi się martwić o inne części. W ten sposób można to łatwo zmienić, jeśli zajdzie taka potrzeba. W przypadku projektów innych niż MVC obowiązki nie są jasne. Przedstawiciel handlowy może próbować zmodyfikować produkt, gdy klient poprosi o coś innego. Lub mogą podawać różne ceny w zależności od tego, jak się czują tego dnia. Dyrektor generalny może być zaniepokojony produkcją, gdy powinien martwić się, jak zapewnić bardziej niezawodny łańcuch dostaw. Pracownicy magazynu mogą być na hali sprzedaży i rozmawiać z klientami, kiedy powinni realizować zamówienia, które zostały już podjęte.

Innymi słowy, dobry projekt MVC pozwala każdej części skupić się na jednej rzeczy, dzięki czemu może to zrobić dobrze - tak jak dobrze zorganizowana firma.

** Oświadczenie - jeśli Twoja firma jest źle zorganizowana, mogą się tym obrazić. W takim przypadku będziesz potrzebować innej analogii. Możesz także potrzebować innej pracy.

Korzyści z MVC polegają przede wszystkim na oddzieleniu obaw:

Pozwala ludziom skoncentrować się na tym, co robią najlepiej.

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

Obniża to koszty, ponieważ powiązane ze sobą systemy wymagają, aby pracownicy byli ekspertami we wszystkich tych obszarach, lub częściej występują problemy, gdy zmiana w jednym obszarze wpływa na inne.

Podaj rzeczywiste przykłady architektury MVC: telefony komórkowe, telefony stacjonarne, Skype itp. Zmiana widoku (typ klawiatury, głośników, mikrofonów) nie wpływa na model (sygnał audio), kontroler jest obwodem w telefon, który przekształca fale dźwiękowe w sygnały audio.

Powiedziałbym im, że MVC rozwiewa moje obawy.

Moją pierwszą troską jest logika kodu - to, co robię za kulisami, aby strona internetowa wykonywała działania, które chcą.

Moim drugim problemem jest logika biznesowa - to, co oni (użytkownik) chcą, aby aplikacja zrobiła.

Moim trzecim problemem jest to, jak wygląda strona - odwiedzana strona robi to, co chce.

(Nie powiem im o następnej części) Więc, moje wyjaśnienia dotyczyły Modelu, Kontrolera i Widoku.

Wyjaśnij zalety

Wyjaśniłbym MVC w kategoriach korzyści biznesowych. Twoi menedżerowie będą w stanie to zrozumieć i włączą się, jeśli zalety będą przekonujące.

MVC pozwala ci podzielić twoją aplikację na rozsądne jednostki, z których każda istnieje niezależnie od innych. Otrzymujesz czysty, łatwy do utrzymania, testowalny kod i potencjalnie ponowne użycie kodu między systemami.

Model

Każdy model zawiera jeden typ informacji biznesowych, na przykład rekord klienta lub produkt, wraz z całą powiązaną logiką biznesową.

Oddzielenie tego pozwala łatwo przetestować logikę biznesową w oderwaniu od innych części aplikacji.

Możesz także z łatwością rozszerzyć aplikację, dodając dodatkowe modele, jest ona bardzo modułowa i czysta.

Każdy model teoretycznie może istnieć niezależnie od innych. Można rozważyć wymuszenie tego za pomocą obiektów usług do obsługi relacji między modelami. Możesz wymieniać modele bez wpływu na resztę systemu.

Widok

Rozdzielenie widoku umożliwia łatwą aktualizację interfejsu użytkownika bez konieczności przerywania jego działania.

Możesz przekazać kod frontonu innemu programistowi, niekoniecznie dając mu dostęp do całego systemu.

Możesz także tworzyć alternatywne interfejsy, które działają z istniejącym systemem. Możesz wyświetlać swoje dane jako aplikację mobilną, interfejs API, plik PDF lub arkusz kalkulacyjny Excel. Możesz to zrobić bez włamywania się do reszty systemu. Jest mniej prawdopodobne, że coś się zepsuje. Możesz łatwo tworzyć punkty integracji dla istniejących systemów, do których można się podłączyć.

Kontroler

Kontroler łączy modele z widokiem. Utrzymuje wszystko osobno. Bardzo łatwo można połączyć w innym widoku. Jeśli zmienisz kod modelu, widok nawet nie musi wiedzieć.

Inne zalety

To wspólny wzór. Inni programiści będą w stanie zrozumieć Twój kod i pracować nad nim. Jeśli wrócisz do kodu po latach, prawdopodobnie będziesz w stanie go zrozumieć i wprowadzić zmiany. Twój kod najprawdopodobniej nie stanie się kolejnym problemem dla przyszłego programisty.

Ponieważ wszystko ma swoje miejsce, znacznie łatwiej jest stworzyć czysty kod. Ryzyko spaghettifikacji jest znacznie zmniejszone (choć nie wyeliminowane). Twój kod staje się łatwy do utrzymania.

Ponieważ wszystko jest modułowe, możesz testować jego części w izolacji. Twój kod jest testowalny i rzadziej zawiera błędy lub dziury w zabezpieczeniach. Przyszłe aktualizacje będą znacznie łatwiejsze, ponieważ będziesz mógł łatwo przetestować cały system.