Model–widok–adapter - Model–view–adapter
Adapter widoku modelu ( MVA ) lub kontroler pośredniczący MVC to wzorzec architektury oprogramowania i architektura wielowarstwowa . W złożonych aplikacjach komputerowych, które prezentują użytkownikom duże ilości danych, programiści często chcą oddzielić obawy dotyczące danych (model) i interfejsu użytkownika (widok), aby zmiany w interfejsie użytkownika nie miały wpływu na obsługę danych i aby dane można było reorganizować bez wprowadzania zmian interfejs użytkownika. Zarówno MVA, jak i tradycyjny MVC próbują rozwiązać ten sam problem, ale z dwoma różnymi stylami rozwiązania. Tradycyjne MVC organizuje model (np. struktury danych i pamięć), widok (np. interfejs użytkownika) i kontroler (np. logikę biznesową) w trójkącie, z modelem, widokiem i kontrolerem jako wierzchołkami, dzięki czemu niektóre informacje przepływają między model i widoki poza bezpośrednią kontrolą kontrolera. Model-widok-adapter rozwiązuje to raczej inaczej niż model-widok-kontroler , rozmieszczając model, adapter lub kontroler pośredniczący i wyświetlając liniowo bez żadnych połączeń bezpośrednio między modelem a widokiem.
Zasady
Widok i model nie komunikują się bezpośrednio
Widok jest całkowicie oddzielony od modelu, dzięki czemu widok i model mogą współdziałać tylko za pośrednictwem kontrolera pośredniczącego lub adaptera między widokiem a modelem. Dzięki temu rozwiązaniu tylko adapter lub kontroler mediacyjny ma wiedzę o modelu i widoku, ponieważ za adaptację lub mediację między modelem a widokiem odpowiada wyłącznie adapter lub kontroler mediacyjny — stąd nazwy adapter i mediator. Model i widok są celowo nieświadome siebie nawzajem. W tradycyjnym MVC model i widok są wzajemnie uświadamiane, co może pozwolić na niekorzystne sprzężenie problemów widoku (np. interfejsu użytkownika) z modelem (np. baza danych) i odwrotnie, gdy architektura mogłaby być lepiej obsługiwana przez schemat bazy danych i prezentacja informacji w interfejsie użytkownika są całkowicie oddzielone od siebie i mogą się od siebie radykalnie odbiegać. Na przykład w edytorze tekstu , model może najlepiej być stół kawałek (zamiast, powiedzmy, bufor szczeliny lub połączonej listy z linii ). Jednak interfejs użytkownika powinien przedstawiać ostateczny stan spoczynku edycji w pliku, a nie bezpośrednią prezentację przeładowanych informacjami o drobiazgowych, surowych deltach cofania i ponawiania z tabeli kawałków i operacji przyrostowych na tym pliku od momentu rozpoczęcia bieżącej sesji edycji.
Model jest celowo nieświadomy poglądów
Ta separacja obaw pozwala na pośredni dostęp do tego samego modelu z wielu różnych widoków za pośrednictwem dokładnie tego samego adaptera lub tej samej klasy adapterów. Na przykład jeden podstawowy model przechowywania danych, schemat i technologia mogą być dostępne za pośrednictwem różnych widoków — np. Qt GUI , Microsoft MFC GUI, GTK+ GUI, Microsoft .NET GUI, Java Swing GUI, Silverlight website oraz AJAX – gdzie ( w przeciwieństwie do tradycyjnego MVC) model jest całkowicie nieświadomy tego, jakie informacje przepływają do tych interfejsów użytkownika . Adapter lub klasa adapterów sprawia, że model jest całkowicie nieświadomy tego, że obsługuje wiele interfejsów użytkownika, a być może nawet obsługuje tę różnorodność jednocześnie. W modelu te różne typy interfejsu użytkownika wyglądałyby jak wiele wystąpień zwykłego użytkownika nieświadomego rodzaju technologii.
Widok celowo nie zwraca uwagi na modele
Podobnie każdy interfejs użytkownika może być celowo nieświadomy wielu różnych modeli, które mogą być podstawą kontrolera lub adaptera pośredniczącego. Na przykład ta sama witryna może być nieświadoma faktu, że może być obsługiwana (A) przez serwer bazy danych SQL , taki jak PostgreSQL , Sybase SQL Server lub Microsoft SQL Server, który ma logikę biznesową wbudowaną w serwer bazy danych za pomocą procedur składowanych i która zawiera transakcje, które serwer może wycofać lub (B) przez serwer bazy danych SQL, taki jak MySQL, który nie ma jednej lub więcej z tych możliwości, lub (C) przez bazę danych innych niż SQL RDF , ponieważ witryna współdziała tylko z kontrolerem pośredniczącym lub adapter, a nigdy bezpośrednio z modelem.
Wiele adapterów między tą samą parą model-widok
Dodatkowo można utworzyć wiele adapterów, aby zmienić sposób, w jaki jeden widok przedstawia dane dla danego modelu. Na przykład, różne adaptery mogą narzucać różne podstawowe zestawy danych, które z kolei narzucają inną logikę biznesową dla tej samej bazowej bazy danych i dla tej samej strony internetowej prezentowanej na zewnątrz. W tym scenariuszu klasa różnych adapterów lub kontrolerów mediacji może reprezentować różnice w logice biznesowej między tym samym modelem bazy danych i tym samym widokiem serwisu WWW.