在準(zhǔn)備這份材料時，我們考慮了架構(gòu)類型的各個方面，以確定每種架構(gòu)類型的優(yōu)缺點。接下來，我剖析了模塊化架構(gòu)的替代方案，以增加討論的多樣性和深度。最后，我提出了總結(jié)性意見，以更好地理解我們的發(fā)現(xiàn)并提供相關(guān)建議。 

IT 領(lǐng)域在開發(fā)移動應(yīng)用程序的架構(gòu)選擇上。已經(jīng)從單體方法向微服務(wù)的轉(zhuǎn)變。然而，模塊化方法已成為具有四種底層類型的優(yōu)越替代方案，即 MVC、MVP、MVVM 和 Viper 移動應(yīng)用程序開發(fā)。 

關(guān)于架構(gòu)類型的決定通常取決于開發(fā)人員的個人經(jīng)驗。在這里，我想闡明各種類型的架構(gòu)之間的差異，特別是作為一種有前途的替代方案。 

要考慮的架構(gòu)的核心方面

架構(gòu)為任何項目提供了強大的基礎(chǔ)，因為它會影響其進一步的開發(fā)潛力和可靠性。架構(gòu)作為以下項目的初始基礎(chǔ)，確定其結(jié)構(gòu)、可擴展性、維護效率和規(guī)模。已完成工作的可靠性和壽命決定了其質(zhì)量和后續(xù)維護效率。單體式方法是最初的架構(gòu)形式。本質(zhì)上，這樣的系統(tǒng)只有一個部署單元，這意味著更高的依賴性和復(fù)雜性。 

通過將單個復(fù)雜流程分解為更小的組件，微服務(wù)成為一種自然的反應(yīng)。然而，隨著時間的推移，很明顯，維護微服務(wù)方法成本高昂并且需要過多的資源。此時，模塊化架構(gòu)通過成為單體方法和微服務(wù)之間的過渡階段而進入框架。

移動應(yīng)用程序開發(fā)繼續(xù)存在于一個沒有明確指導(dǎo)或通用規(guī)則的領(lǐng)域。這種狀況的形成部分是因為每個特定項目的獨特需求和要求。因此，在為 iOS 和 Android 開發(fā)應(yīng)用程序時考慮特定因素至關(guān)重要： 

項目類型

操作系統(tǒng)

SDK 和工具集

云技術(shù)

數(shù)據(jù)庫和服務(wù)器基礎(chǔ)設(shè)施

數(shù)據(jù)格式化

擴展計劃

第三方服務(wù)

導(dǎo)航的復(fù)雜性

用戶界面/用戶體驗

內(nèi)容

預(yù)算和時間限制

團隊技能水平

優(yōu)質(zhì)應(yīng)用架構(gòu)的特征

可以列出開發(fā)良好的應(yīng)用程序架構(gòu)的幾個特定品質(zhì)，包括：

可靠性——定義顯示代碼部分相互交互的特征，消除應(yīng)用程序中的不穩(wěn)定性和不一致。

可擴展性——架構(gòu)的靈活性反映了其增長和調(diào)整的潛力。計劃更改和新功能以及以新操作系統(tǒng)和庫的形式進行改進是很自然的。

關(guān)注點分離——實體應(yīng)該在代碼中保持分離，以確保它們的重復(fù)使用、易于調(diào)試，以及在不影響系統(tǒng)中其他組件的情況下隔離頻繁更改的組件。

可測試性——架構(gòu)應(yīng)該支持單獨測試用例和功能，以避免運行時出現(xiàn)任何阻止長時間修復(fù)的問題。此外，QA 將獲得單獨測試功能和編寫測試用例的能力。 

維護效率——通過防止超支和過度的資源分配來優(yōu)化成本。 

易于使用- 有助于在編寫和閱讀方面簡化代碼。 

關(guān)鍵的模塊化架構(gòu)類型

MVC、MVP、MVVM 和 Viper 是主要的移動應(yīng)用程序開發(fā)類型，具有單獨的特定使用變化子樹。可以選擇單一類型或兩種或多種的混合。在做出選擇之前，重要的是在細節(jié)和特定應(yīng)用案例方面對它們進行比較。 

一、MVC

第一種類型是移動應(yīng)用程序開發(fā)中最常用的 MVC 或模型-視圖-控制器排名。 

MVC 支持創(chuàng)建具有簡單內(nèi)容、全面導(dǎo)航邏輯、統(tǒng)一用戶體驗以及標(biāo)準(zhǔn)化 UI 設(shè)計的基本跨平臺應(yīng)用程序。任務(wù)實現(xiàn)通常遵循從加載到顯示的模式，中間沒有額外的步驟或階段。  

使用 MVC 的原因通常包括需要加速開發(fā)過程和/或提供直接的簡單流程。它在創(chuàng)建普通客戶端/服務(wù)器應(yīng)用程序和處理簡單數(shù)據(jù)方面也是可行的。MVC 在獲取未格式化的數(shù)據(jù)結(jié)果、創(chuàng)建對 SEO 友好的平臺以及管理屏幕上的單向指令流時非常有效。

二、MVVM

MVVM 或模型-視圖-視圖-模型根據(jù)其具體情況和應(yīng)用程序能力在其使用頻率上排名第二。

將 UI 邏輯與業(yè)務(wù)邏輯分離的可能性是 MVVM 與 MVC 之間的主要區(qū)別。這種改變允許實現(xiàn)更復(fù)雜的功能任務(wù)，并為用戶與移動應(yīng)用程序提供額外的動作和交互選擇。由于測試的業(yè)務(wù)邏輯與 UI 合并分離，自動測試可用于實施。 

開發(fā)人員通常將 MVVM 用于更高復(fù)雜性的應(yīng)用程序，該應(yīng)用程序具有更通用的模式特性。因此，MVVM 對于希望在短期內(nèi)擴展功能的小型項目特別有效。 

三、MVP

第三種模塊化架構(gòu)是與 MVC 類型并行使用的 MVP 或模型-視圖-展示器。 

數(shù)據(jù)顯示和用戶與應(yīng)用程序交互的差異決定了 MVVM 和 MVP 之間的選擇。模型和視圖是 MVP 類型唯一可用的測試工具。

如果應(yīng)用程序內(nèi)的 UI 組件集有限且導(dǎo)航流簡單，則開發(fā)人員會使用 MVP。

四、Viper

VIPER 或 View、Interactor、Presenter、Entity 和 Router 模型是一種模塊化架構(gòu)或用于實施長期項目的模式。在這種架構(gòu)上開發(fā)應(yīng)用程序的過程需要更長的啟動時間，因為它偏向于純粹的單體類型。 

VIPER 支持干凈的代碼想法。它需要對編程領(lǐng)域有深入的了解和理解。這種架構(gòu)模式提供了良好的測試覆蓋率、新功能實現(xiàn)的隔離以及責(zé)任區(qū)域的依賴性。具有此架構(gòu)的項目需要 2 個或更多開發(fā)人員來構(gòu)建跨平臺移動應(yīng)用程序。

具有特定技術(shù)要求的長期項目受益于使用 Viper。

模塊化架構(gòu)的好處

模塊化架構(gòu)提供了幾個基本原則，這些原則可以轉(zhuǎn)化為開發(fā)人員的利益： 

強封裝——通過隱藏組件內(nèi)的實現(xiàn)細節(jié)來確保不同部分之間的低耦合。該團隊獲得了在分離的系統(tǒng)部件上單獨工作的能力。

顯式依賴——提供不同組件的強大表達和驗證，允許它們一起工作。

定義良好的接口– 組件之間穩(wěn)定且定義良好的 API，可以用實現(xiàn)替換組件 

總結(jié)：

模塊化架構(gòu)提供了一系列用于開發(fā)移動應(yīng)用程序的工具。四種討論的模塊化架構(gòu)類型，即 MVC、MVVM、MVP 和 Viper，都具有適合各自情況的細節(jié)和應(yīng)用。較小的項目受益于 MVC 替代方案，因為它提供了簡單的內(nèi)容、UI 和導(dǎo)航。MVVM 和 MVP 更適合大型項目。兩者之間的區(qū)別源于數(shù)據(jù)顯示和 UI 上的負載。 

Viper 適用于性質(zhì)較長的大型項目以及需要開發(fā)自定義應(yīng)用程序的項目。模塊化架構(gòu)通過利用整體方法作為基礎(chǔ)提供微服務(wù)的強大替代方案，但隔離部分以確保獨立性和靈活性。 

開發(fā)人員在對每個項目進行單獨分析后，根據(jù)具體情況做出架構(gòu)選擇。這樣的選擇依賴于每個架構(gòu)類型和子類型的特性。對項目的清晰理解以及將其投射到開發(fā)過程中的能力決定了架構(gòu)的類型。