Jak projektuje się aplikacje: zrozumienie architektury

Spis treści:

• Jewgienij Jołczew
• Czym jest architektura MVC
• Dlaczego MVC nie działało w moich projektach
• Jak stworzyłem system zarządzania serwerami VDS
• Dlaczego architektura nie jest najważniejsza w projekcie
• Czym tak naprawdę jest MVC?
• Jak zrozumieć dowolną architekturę
• Wniosek: co warto przeczytać o architekturze

Jewgienij Jołczew

Ekspert to profesjonalista posiadający dogłębną wiedzę i doświadczenie w określonej dziedzinie. Eksperci odgrywają kluczową rolę w różnych dziedzinach, takich jak nauka, technologia, biznes i sztuka. Ich umiejętności i porady często stanowią podstawę podejmowania decyzji i opracowywania strategii. W dzisiejszym świecie eksperci są poszukiwani w zakresie analizy danych, badań i doradztwa, co przyczynia się do rozwoju i doskonalenia procesów w różnych branżach. Aby zostać ekspertem, potrzebne jest nie tylko wykształcenie teoretyczne, ale także doświadczenie praktyczne, które pozwala identyfikować i rozwiązywać złożone problemy. Ekspertyza obejmuje również umiejętność dzielenia się wiedzą i nauczania innych, co przyczynia się do rozpowszechniania informacji i zwiększa ogólny poziom kompetencji w społeczności.

O autorze

Autor tego materiału ma duże doświadczenie w zakresie pisania i edytowania treści. Jego prace obejmują różnorodną tematykę i gatunki, co pozwala mu tworzyć wysokiej jakości, pouczające teksty. Autor dąży do dostarczania czytelnikom istotnych i przydatnych informacji, koncentrując się na optymalizacji SEO w celu poprawy widoczności materiałów w wyszukiwarkach. Dzięki dogłębnemu zrozumieniu potrzeb odbiorców, autor jest w stanie dostosować styl i ton tekstu, aby jak najskuteczniej przekazać czytelnikowi idee.

Starszy programista iOS w VKontakte. Wcześniej pracował jako programista full-stack, koncentrując się na backendzie i DevOps, a także zarządzał działem rozwoju aplikacji mobilnych. Przez trzy lata wykładał programowanie iOS w GeekBrains i pełnił funkcję dziekana wydziału. Jest członkiem komitetu programistycznego konferencji Podlodka iOS Crew i prowadzi kanał YouTube z samouczkami wideo na temat Fluttera. Jest aktywny na Twitterze pod nazwą @tygeddar.

Linki odgrywają ważną rolę w strukturze i nawigacji stron internetowych. Pomagają użytkownikom poruszać się między stronami i znajdować potrzebne informacje. W kontekście SEO, wysokiej jakości i trafne linki pomagają poprawić widoczność witryny w wyszukiwarkach. Ważne jest, aby używać zarówno linków wewnętrznych, jak i zewnętrznych. Linki wewnętrzne pomagają rozłożyć ciężar strony i kierować użytkowników do innych sekcji witryny, podczas gdy linki zewnętrzne kierują do zasobów, które mogą być przydatne dla użytkowników i zwiększają autorytet treści. Optymalizacja linków polega na użyciu słów kluczowych w tekście linku, co również pomaga w poprawie SEO. Prawidłowe formatowanie i struktura linków mogą znacząco poprawić doświadczenia użytkowników i przyczynić się do lepszych pozycji w wynikach wyszukiwania.

Z pasją debatuję nad tym, która architektura jest najskuteczniejsza. Być może wynika to z mojego zamiłowania do perfekcji lub z mojego wykształcenia w zakresie architektury systemów informatycznych. Być może również nie chcę tracić czasu na analizowanie nieudanych projektów.

Architektura MVC zajmuje szczególne miejsce w moich preferencjach. W tym artykule wyjaśnię, jak działa i dlaczego nie jestem entuzjastą innych podejść architektonicznych, takich jak MVVM, MVP i VIPER. Niedawno zbadałem również Flux i jego implementację w Redux i doszedłem do wniosku, że to podejście również mi się nie podoba. MVC zapewnia przejrzystą strukturę, która oddziela dane, logikę i prezentację, ułatwiając tworzenie i testowanie. W przeciwieństwie do innych architektur, które mogą zwiększać złożoność, MVC zachowuje przejrzystość i ułatwia zrozumienie kodu.

W tym artykule analizujemy wątek autora na Twitterze, zgłębiając główne idee i tematy poruszane w jego wiadomościach. Autor dzieli się swoją unikalną perspektywą i doświadczeniem, dzięki czemu wątek jest interesujący i istotny w dyskusji. Wątek koncentruje się na kluczowych kwestiach nurtujących użytkowników, a także na możliwych rozwiązaniach i rekomendacjach. Takie podejście pozwala na głębsze zrozumienie omawianych problemów i sprzyja konstruktywnemu dialogowi. Wątek staje się platformą wymiany opinii i pomysłów, czyniąc go cennym źródłem informacji dla subskrybentów i szerszej publiczności.

Czym jest architektura MVC?

Po raz pierwszy zetknąłem się z architekturą Model-View-Controller (MVC) w 2009 roku, ucząc się frameworka internetowego Zend. Dokumentacja frameworka wyjaśniała, że ​​Model reprezentuje bazę danych, Widok to szablon HTML, a Kontroler to logika, która pobiera dane z bazy danych, przetwarza je i umieszcza w szablonie w celu późniejszego dostarczenia użytkownikowi. Ten model architektoniczny znacznie uprościł tworzenie aplikacji internetowych poprzez oddzielenie logiki przetwarzania danych, prezentacji informacji i interakcji z użytkownikiem. MVC stał się standardem w tworzeniu stron internetowych, zapewniając przejrzysty kod oraz łatwą konserwację i skalowalność.

W tamtym czasie studiowałem, pisałem prace semestralne i rozwijałem ulubione projekty. Projekty te charakteryzowały się złożonymi układami i zawiłymi strukturami baz danych, ale logika pozostawała dość prosta. Mimo to byłem zadowolony z mojego podejścia do pisania kodu, ponieważ było jasne i zrozumiałe. Ten styl programowania pozwolił mi skupić się na doskonaleniu umiejętności i zrozumieniu podstaw programowania.

Nigdy nie brałem pod uwagę możliwości działania inaczej niż wskazano w dokumentacji narzędzia i przykładach na forum. Byłem zadowolony z mojego podejścia i nie rozpraszały mnie niepotrzebne myśli.

Wątpliwości co do mojego podejścia pojawiły się po przeczytaniu artykułów na Habr, które argumentowały, że logika powinna być zintegrowana z modelem, aby kontroler był jak najprostszy. To doprowadziło mnie do zrozumienia dwóch wersji modelu architektonicznego MVC: kontrolera o małej i dużej architekturze. Każde z tych podejść ma swoje wady i zalety i ważne jest, aby wybrać to, które najlepiej odpowiada wymaganiom danego projektu. Cienki kontroler ułatwia testowanie i konserwację kodu, podczas gdy gruby kontroler zapewnia większą elastyczność w zarządzaniu logiką aplikacji.

Zmieniłem strukturę mojego projektu, przenosząc logikę z jednego pliku do drugiego. Nie zaszły jednak żadne znaczące zmiany. W rezultacie kod po prostu trafił w nowe miejsce, ale funkcjonalność pozostała taka sama.

Po przeczytaniu dyskusji online i przeanalizowaniu własnych przemyśleń doszedłem do wniosku, że nie lubię „grubego” modelu. Lepiej, aby model pozostał bazą danych, a kontroler nadal zarządzał logiką aplikacji. Takie podejście zapewnia wyraźny podział obowiązków i ułatwia konserwację i rozwój kodu.

Z czasem złożoność moich projektów wzrosła, a kontrolery stały się bardziej nieporęczne (choć nie tak bardzo jak UIViewController w iOS). Próbowałem rozwiązać ten problem, przenosząc logikę do oddzielnych plików, które połączyłem z kontrolerami. Nie doprowadziło to jednak do znaczących zmian: architektura pozostała ta sama, a kod został po prostu przeniesiony z jednego pliku do drugiego.

Dlaczego MVC nie sprawdziło się w moich projektach

W 2013 roku przeszedłem na Laravel, poznałem mechanizm automatycznego ładowania klas w PHP i zgłębiłem podstawy programowania obiektowego. Przeczytałem również książkę Steve'a McConnella „Code Complete”, która znacząco poszerzyła moją wiedzę na temat tworzenia oprogramowania.

Stało się jasne, że łączenie całego kodu w jednym pliku jest niepraktyczne. Kod i klasy powinny strukturyzować projekt, a niektóre jego fragmenty lepiej jest wydzielić z architektury MVC i umieścić w osobnych modułach. Zwiększy to możliwości ponownego wykorzystania i uprości konserwację kodu. Podział na komponenty poprawia zarządzanie i sprzyja bardziej efektywnemu rozwojowi.

Od tego momentu zmieniłem podejście do rozwoju projektu. Wprowadziłem hierarchię klas, która uporządkowała przechowywanie logiki, dzięki czemu kontroler stał się lżejszy. Zaczął on pobierać dane z bazy danych, przekazywać je do różnych modułów, odbierać wyniki przetwarzania i wysyłać je na stronę HTML. To nowe podejście poprawiło strukturę kodu i uprościło jego konserwację, co pozytywnie wpłynęło na wydajność i skalowalność projektów.

Architektura projektu nie była optymalna dla złożonych systemów, ale idealnie pasowała do moich zadań. To podejście zapewniło czytelność kodu i zachowało niezależność różnych elementów projektu, co przyczyniło się do wydajnego rozwoju i uproszczonego wsparcia.

Jak zbudowałem system zarządzania serwerem VDS

Jakościowy skok w mojej karierze nastąpił, gdy przeszedłem z tworzenia stron internetowych do backendu. Na tym nowym stanowisku musiałem zaprojektować i rozwinąć złożony system zarządzania serwerem VDS. W tym procesie tworzyłem interfejsy API, tworzyłem wtyczki i zarządzałem ich zależnościami. Wykorzystywałem również kod asynchroniczny i obsługiwałem wiele trybów działania, współpracując z systemem operacyjnym i różnorodnym oprogramowaniem. Głównym celem projektu było stworzenie jądra systemu, a także opracowanie niezależnych wtyczek, które mogą efektywnie ze sobą współdziałać.

W złożonych systemach przesyłanie wszystkich danych przez pojedynczy kontroler jest niepraktyczne. Dlatego każda wtyczka tworzy oddzielne interfejsy webowe i API, co pozwala na efektywne zarządzanie dostępem do danych i implementację logiki biznesowej. Elementy te są zorganizowane w pakiety, co zapewnia ich ponowne wykorzystanie i upraszcza integrację z systemem, zwiększając jego elastyczność i skalowalność.

HTML i JavaScript współdziałają ze sobą, dostarczając modele i komunikację z API. W tej strukturze API pełni rolę łącza, umożliwiając wykorzystanie pakietów wielokrotnego użytku do implementacji logiki biznesowej i dostępu do danych. Model ten nie do końca odpowiada klasycznej architekturze MVC.

Po przejściu na rozwój iOS, tymczasowo odłożyłem na bok kwestie architektoniczne. W tym okresie skupiłem się na nauce UIKit i intuicyjnym rozmieszczaniu komponentów interfejsu. HTML i CSS zostały przekształcone w różne UIViews, a cienki kontroler stał się UIViewController. Logika biznesowa została zaimplementowana za pomocą usług, co pozwoliło na stworzenie bardziej ustrukturyzowanej aplikacji.

Dlaczego architektura nie jest najważniejsza w projekcie

Odniosłem sukces z architekturą MVC, ale eksperymentowałem również z innymi podejściami. Wiele osób podzieliło się swoimi wrażeniami na temat tego, jak architektury MVVM, MVP i VIPER ułatwiają im pracę, więc postanowiłem przetestować je w moich projektach.

Obserwując, jak inne firmy wdrażają swoje procesy, poznałem kilka kluczowych aspektów.

Architektura oprogramowania nie zawsze zapewnia wyraźne korzyści. Żadna nowoczesna architektura nie okazała się skuteczniejsza niż metody, których używałem na początkowych etapach rozwoju. W trakcie mojej pracy wypróbowałem różne podejścia i byłem w stanie ocenić ich rzeczywistą wartość dla projektu. Jednak między wzorcami architektonicznymi, takimi jak MVC i MVP, różnica polega jedynie na nazwach klas i niektórych regułach interakcji elementów, a nie na ich funkcjonalności.

Firmy różnie interpretują podejścia architektoniczne. Niektóre używają MVVM, podczas gdy inne nazywają to samo podejście MVC. Spotkałem się z pięcioma różnymi systemami MVVM i każdy z nich miał swoje własne cechy charakterystyczne. Wyjątkiem jest VIPER, który dzięki pracom Jegora Tołstoja posiada szczegółową dokumentację i liczne przykłady. Jednak nawet w tym przypadku różnice w implementacji mogą być zauważalne.

Popularna architektura nie zawsze jest najlepszym wyborem dla projektu. Wybór podejścia architektonicznego wyłącznie na podstawie jego popularności może prowadzić do nieefektywnych rozwiązań. Na przykład niektórzy programiści wybierają MVVM, ale umieszczają te same komponenty w różnych częściach projektu, co może zaburzyć logikę i strukturę aplikacji. Ważne jest, aby wziąć pod uwagę specyfikę projektu, jego wymagania i charakterystykę zespołu, a nie podążać za trendami. Prawidłowy wybór architektury powinien opierać się na funkcjonalności, łatwości utrzymania i skalowalności aplikacji.

Architektura projektu nie jest panaceum. Nie jest w stanie samodzielnie rozwiązać problemów i nie gwarantuje sukcesu. Kluczowymi czynnikami sukcesu projektu są nie tylko decyzje architektoniczne, ale także skuteczne zarządzanie, wysokiej jakości planowanie i kompetentna implementacja. Bez kompleksowego podejścia architektura pozostaje jedynie teoretyczną podstawą, która wymaga praktycznej implementacji i ciągłej adaptacji do zmieniających się warunków.

Czym tak naprawdę jest MVC?

Nieustannie badam architektury oprogramowania, studiuję literaturę i omawiam pomysły z kolegami. Wielokrotnie przemyślałem i zmieniłem zdanie na temat modelu MVC opracowanego w Smalltalku.

Doszedłem do wniosku, że wzorzec architektoniczny MVC to nie tylko zestaw trzech plików lub klas dla każdego komponentu. Model nie ogranicza się do danych ani logiki biznesowej, a kontroler traci na znaczeniu. W nowoczesnym tworzeniu stron internetowych wskazane jest rozważenie wykorzystania MV (Model-View) w celu efektywniejszej organizacji kodu i poprawy interakcji między komponentami. Takie podejście pozwala skupić się na widoku i modelu, co przyczynia się do tworzenia bardziej elastycznych i skalowalnych aplikacji.

Aplikacje z logiką biznesową i dostępem do danych istniały przed pojawieniem się MVC, ale brakowało im w pełni rozwiniętego interfejsu użytkownika. Głównym celem MVC jest zapewnienie komunikacji między interfejsem użytkownika a pozostałymi komponentami aplikacji. Twórca MVC zaleca, w razie potrzeby, utworzenie oddzielnej fasady dla każdego widoku, który będzie oddziaływał z modelem. Ważne jest również użycie wzorca obserwatora do śledzenia zmian i aktualizacji danych w interfejsie. Poprawia to strukturę aplikacji, zwiększa jej skalowalność i upraszcza konserwację kodu.

Widok reprezentuje interfejs użytkownika, podczas gdy model obejmuje resztę aplikacji. Głównym celem kontrolera nie jest działanie jako warstwa pośrednicząca między widokiem a modelem, lecz efektywne przetwarzanie danych wprowadzanych przez użytkownika. Takie podejście pozwala na uzyskanie bardziej przejrzystej architektury aplikacji, w której każdy komponent spełnia swoją własną, unikalną rolę.

Zasada MVC (Model-Widok-Kontroler) polega na oddzieleniu interfejsu użytkownika, logiki biznesowej i interakcji z bazą danych, zapewniając bardziej ustrukturyzowane i łatwiejsze w zarządzaniu podejście do tworzenia aplikacji. Zasada ta pozwala programistom skupić się na poszczególnych komponentach bez wzajemnego zakłócania ich funkcjonalności. Implementacja tego podejścia leży w gestii architekta, który jest odpowiedzialny za zaprojektowanie architektury aplikacji. MVC nie jest złożoną koncepcją, ale wymaga starannego planowania, aby system działał efektywnie.

MVP, MVVM i VIPER nie zastępują architektury MVC, lecz ją uzupełniają. We współczesnych aplikacjach kontroler traci swoją dawną rolę, ponieważ zarządzanie danymi wejściowymi jest teraz obsługiwane bezpośrednio przez widok. Ta zmiana sprawia, że ​​widok staje się integralną częścią architektury, promując wyraźniejszy podział zadań w aplikacji.

Wzorce architektoniczne Apple MVC, MVVM i inne to modyfikacje modelu widoku. Te warianty często eliminują kontroler, upraszczając strukturę aplikacji. Spośród nowoczesnych wzorców MV(x), MVVM jest najbliższy klasycznemu modelowi MVC, zachowując jednocześnie podstawowe zasady podziału zadań i upraszczając interakcje między komponentami. MVVM umożliwia lepsze zarządzanie stanem widoku i łatwiejsze testowanie, co czyni go popularnym wyborem w tworzeniu nowoczesnych aplikacji.

Złożona terminologia może utrudniać komunikację, szczególnie w dziedzinie architektury. Głównym celem architektury jest uproszczenie i poprawa zrozumienia. Zamiast wprowadzać zamieszanie, architektura powinna ułatwiać dostęp do informacji i ułatwiać dostęp do nich wszystkim.

Jak zrozumieć dowolny Architektura

Architektura Mogą wydawać się monotonne, ale to błędne przekonanie. Każda architektura ma swoje unikalne cechy i wymaga wnikliwej analizy. Mam kilka kluczowych zasad, które pomagają w ocenie i zrozumieniu rozwiązań architektonicznych.

Implementacja jest kluczowym aspektem udanego projektu. Ogólna architektura nie jest tak ważna, jak jej praktyczna implementacja. Nazewnictwo klas, układ elementów i interakcje między klasami to istotne czynniki. Aby zapewnić łatwość utrzymania projektu, cały zespół powinien przestrzegać ustalonych standardów. Takie podejście poprawia kod, zwiększa jego czytelność oraz ułatwia rozwój i późniejszą konserwację.

Za model odpowiadasz Ty. Architektura MVC nie zapewnia jasnych wytycznych dotyczących tworzenia głównej części aplikacji. Twoim zadaniem jest uniknięcie zamieszania w modelu, w którym niektóre klasy pełnią funkcje usługowe, a inne zadania pomocnicze. Prawidłowa struktura modelu ma kluczowe znaczenie dla utrzymania przejrzystości i czytelności kodu. Rozdziel obowiązki klas i przestrzegaj zasad pojedynczej odpowiedzialności, aby zapewnić łatwość utrzymania i rozwoju aplikacji.

Aby skutecznie opanować programowanie, ważne jest, aby zacząć od podstaw. Zamiast koncentrować się na konkretnej architekturze, musisz zrozumieć logiczne zasady, na których się opiera. Pomocna jest znajomość historii programowania oraz podejście obiektowe i funkcyjne. Studiowanie wzorców projektowych i zasad SOLID znacząco pogłębi Twoją wiedzę. To lektura obowiązkowa, podobnie jak książka Steve'a McConnella „Code Complete”, która zawiera ważne wskazówki dotyczące pisania wysokiej jakości kodu.

Po opanowaniu podstaw warto zapoznać się z architekturą Flux i biblioteką Redux. Warto rozważyć te technologie, ponieważ Facebook opracował szczegółowy przewodnik po Flux i wydał odpowiednią bibliotekę. Warto zauważyć, że Flux również opiera się na zasadach MVC, gdzie model (M) i widok (V) są oddzielone, a widok reaguje na zmiany w modelu. Warto jednak pamiętać o dodatkowych ograniczeniach, które są różnie interpretowane. Studiowanie tych technologii pozwoli Ci lepiej zrozumieć zarządzanie stanem w aplikacjach i poprawić jakość programowania.

Redux to potężne narzędzie do zarządzania stanem aplikacji, ale nie jest pozbawione wad. Pracując nad projektem, który sam rozwijałem i utrzymywałem, starałem się przestrzegać najlepszych praktyk. Starannie dobierałem nazwy wszystkich komponentów, łącząc ze Sklepem tylko początkową scenę, a nie wszystkie widoki. Pomogło to uniknąć niepotrzebnej złożoności. Zgrupowałem również oprogramowanie pośredniczące i reduktory, łącząc je ze stanem aplikacji. Takie podejście pomogło zoptymalizować interakcje komponentów i zapewnić bardziej zrozumiałą architekturę.

W pewnym momencie zacząłem gubić się w projekcie. Nagromadziłem wiele encji o podobnych nazwach i danych, co doprowadziło do powstania dużej liczby akcji. W rezultacie byłem zdezorientowany, nie rozumiejąc, które elementy ze sobą oddziałują i jak są ze sobą powiązane. Zarządzanie projektem stało się skomplikowane i zawiłe, co negatywnie wpłynęło na jego rozwój i wydajność pracy.

Kod został zaprojektowany z myślą o rozszerzalności i łatwości utrzymania, ale wszelkie zmiany wymagały edycji wielu plików, co stwarzało znaczne trudności. Było to szczególnie nasilone przez wykorzystanie w projekcie architektury szablonowej Fluttera, co zwiększyło ilość pracy i złożoność.

Redux idealnie nadaje się do dużych projektów nastawionych na pracę offline, w których wiele asynchronicznych i nieblokujących zdarzeń występuje jednocześnie. W takich przypadkach uzasadniony jest kod szablonowy oparty na Reduxie, ponieważ znacznie upraszcza zarządzanie stanem aplikacji i może zapobiec wielu problemom. Jednak w przypadku typowych projektów typu thin-client bardziej sensowne jest użycie standardowych wzorców projektowych, takich jak MV, które pozwalają uniknąć niepotrzebnej złożoności i skupić się na rozwijaniu funkcjonalności.

Wniosek: Co warto wiedzieć o architekturze

Architektura aplikacji odgrywa kluczową rolę w jej rozwoju i powinna być dobrze zrozumiana przez cały zespół. Tworząc aplikację w SwiftUI, preferuję klasyczną architekturę MV, która zakłada interakcję widoku z modelem. Wielu programistów nazywa to podejście MVVM. Zalecam przestrzeganie tej zasady, aby zapewnić przejrzystość i łatwość obsługi podczas pracy nad projektem. Prawidłowa architektura nie tylko upraszcza proces rozwoju, ale także ułatwia utrzymanie i skalowalność aplikacji w przyszłości. Habr oferuje doskonałe artykuły na temat wzorca MVC, takie jak „Polowanie na mityczny MVC: przegląd, powrót do źródeł i jak samodzielnie analizować i tworzyć szablony” oraz „Polowanie na mityczny MVC: tworzenie interfejsu użytkownika”. Zdecydowanie warto zapoznać się z tymi materiałami, jeśli interesuje Cię architektura oprogramowania, ponieważ autor szczegółowo i za pomocą przykładów wyjaśnia istotę wzorca MVC i jego zastosowanie w programowaniu.