Home-theater-designers
Moderna applikationer behöver så många olika funktioner att processen att utveckla dem har vuxit i storlek och komplexitet. För att hjälpa till kan du använda ett arkitektoniskt designmönster. De stödjer byggandet av applikationer som är enkla att testa och underhålla.
De tre mest populära designmönstren är MVC, MVP och MVVM. MVC står för modell, vy och styrenhet, medan MVP står för modell, vy och presentatör, och MVVM för modell, vy och vymodell.
Arkitektoniska och designmönster
Arkitektoniskt mönster
Ett arkitektoniskt mönster förtydligar och definierar några avgörande komponenter i en mjukvaruarkitektur. Även om ett arkitektoniskt mönster förmedlar en bild av ett system, det är inte en arkitektur . I själva verket är det en allmän och återanvändbar lösning på ett vanligt förekommande problem inom mjukvaruarkitektur i ett visst sammanhang.
hur mycket data använder streaming video
Design mönster
Ett designmönster är en formaliserad bästa praxis som du kan använda för att lösa vanliga problem när du designar en applikation eller ett system.
Skillnaden mellan arkitektoniskt och designmönster
Låt oss börja med den vanliga termen — mönster. I mjukvara är ett mönster en återkommande egenskap som låter dig bryta ner en enorm och komplex struktur i mindre, enklare komponenter. Du kan använda det här mönstret för att skapa en allmän lösning för en klass av problem.
På varje nivå av mjukvaruutveckling kommer du att använda olika verktyg. På mindre nivåer är dessa verktyg designmönster. Arkitektoniska mönster finns på större nivåer, och programmeringsparadigm på genomförandenivå.
Varför behöver vi arkitektoniska designmönster?
Under mjukvaruutveckling kan du använda arkitektoniska designmönster för att lösa vanliga problem. Bra arkitektur kan också hjälpa dig att:
- Dela upp komplexa uppgifter i enklare uppgifter.
- Minska buggar.
- Producera testbar och underhållbar kod.
Men utan ett arkitektoniskt mönster kan du få svårigheter att upprätthålla din apps affärslogik.
Modell, View, ViewModel, Controller och Presenter
Innan du tittar på varje mönster, här är termerna som utgör dem:
- Modell lagrar data och kommunicerar direkt med databasen. Modell är den del som representerar din data och applikationslogik. Den definierar affärsreglerna som hanterar datahantering, modifiering eller bearbetning.
- Se visar modellens data och ansvarar för datas representation i användargränssnittet.
- ViewModel är exklusivt för MVVM-mönster. Detta är en abstraktion av vylagret och fungerar också som ett omslag för modelldata.
- Kontroller är den komponent som integrerar vyn och modellen.
- Presentatör är en komponent som bara finns i MVP-modellen. Presentatören får input från vykomponenten och bearbetar data med hjälp av modellen.
MVC-, MVP- och MVVM-mönster
Model-View-Controller-mönster
De MVC arkitektoniska mönster var den första, och den är populär idag inom webbapplikationer. Den introducerades på 1970-talet. Detta mönster låter dig bygga en applikation kring Separation of Concerns (SoC). Det underlättar ansträngningen du behöver för att testa, underhålla och utveckla din applikation.
I MVC-mönstret har modellen ingen förståelse för vyn eller styrenheten. Modellens observatör kommer att få en varning när det sker en förändring i vyn och styrenheten. Styrenheten hjälper routingprocessen att koppla modellen till den relevanta vyn.
Några av MVC-mönstrets fördelar är:
- Separering av bekymmer (mer fokuserad).
- Gör det enklare att testa och hantera koden.
- Främjar frikoppling av applikationens lager.
- Bättre kodorganisation och återanvändbarhet.
Så här fungerar MVC:
Tack vare SoC kan MVC minska kodstorleken och göra en bra kod som är ren och hanterbar.
Model-View-Present-mönster
MVP-mönstret delar två komponenter med MVC: modell och vy. Den ersätter kontrollenheten med presentatören. Presentatören – som namnet antyder – används för att presentera något. Det gör att du lättare kan håna utsikten.
I MVP har presentatören funktionaliteten som 'mellanmannen' eftersom all presentationslogik skjuts till den. Vyn och presentatören i MVP är också oberoende av varandra och interagerar via ett gränssnitt.
Här är en illustration av hur MVP-mönstret fungerar:
dataöverföring från telefon till dator
Presentatören får input från användaren via vyn. Den bearbetar sedan användarens handlingar med hjälp av modellen och skickar resultaten tillbaka till vyn. Presentatören kommunicerar med vyn genom gränssnitt.
Model-View-ViewModel Pattern
MVVM är den moderna utvecklingen av MVC. Huvudmålet med MVVM är att ge en tydlig separation mellan domänlogiken och presentationslagret. MVVM stöder tvåvägsdatabindning mellan vy och vymodell.
MVVM-mönstret låter dig separera din kods vy och modell. Detta betyder att när modellen ändras behöver vyn inte göra det, och vice versa. Med hjälp av en vymodell kan du göra enhetstestning och testa ditt logiska beteende utan att involvera din vy.
Här är en illustration av hur MVVM fungerar:
När ska man använda MVC, MVP och MVVM
Nu när du har lärt dig om varje mönster, ta reda på när du ska använda dem.
När ska man använda MVC
MVC är helt enkelt en implementering av Separation of Concerns. Om din applikation behöver separera data (modell), dataknäppning (kontroller) och datapresentation (vy), kommer MVC att fungera bra. MVC fungerar också bra i en applikation där datakällan och/eller datapresentationen kan ändras när som helst.
När ska man använda MVP
Du kan använda MVP när din applikation har ett dubbelriktat flöde. Om användarinteraktioner behöver begära något från modellen, och resultatet av denna begäran kommer att ändra användargränssnittet omedelbart, överväg MVP.
När ska man använda MVVM
Du vill använda MVVM när:
- Du behöver dela ett projekt med en designer och design- och utvecklingsarbetet kan ske självständigt.
- Du behöver enhetstestning för dina lösningar.
- Du behöver ha återanvändbara komponenter, både inom och över projekt i din organisation.
- Du vill ha mer flexibilitet för att ändra dina åsikter utan att behöva omfaktorisera annan logik i kodbasen.
Vilket mönster ska du välja?
Det främsta skälet till att använda ett designmönster är att minska komplexiteten. Du kan göra detta genom att minska den övergripande komplexiteten eller genom att ersätta obekant komplexitet med den välbekanta. Om ett designmönster inte kan minska komplexiteten på något av dessa två sätt, använd inte något av det; det kommer inte att tillföra något som helst värde.
Om du verkligen är säker på att du ska använda ett designmönster, försök att göra en checklista. Basera det på de situationer du har sett här och välj den som passar bäst för ditt projekt.
hur man gör detaljerad pixelkonst