在本系列中，我們將討論如何使用 wordpress 構建 web 應用程序。盡管這不是一個我們將研究代碼的技術系列，但我們涵蓋了框架、基礎、設計模式、架構等主題。
如果您還沒有閱讀該系列的第一篇文章，我推薦您閱讀；但是，出于本文的目的，我們可以將上一篇文章總結如下：
簡而言之，軟件可以構建在框架上，軟件可以擴展基礎。
簡單地說，我們區(qū)分了框架和基礎——這兩個術語在軟件中經(jīng)常互換使用，盡管它們不是同一件事。 WordPress 是一個基礎，因為它本身就是一個應用程序。它不是一個框架。
為此，當涉及到在 WordPress 上構建 Web 應用程序時，我們需要重新思考架構或重新考慮如何構建應用程序的概念模型。
Web 應用程序的結構
在盡可能高的級別上，Web 應用程序通常由以下三個組件構成：
- 數(shù)據(jù)庫層
- 應用層
- 表示層
一般來說，表示層就是用戶看到的、用戶交互的。它包括將某些內容呈現(xiàn)在用戶面前所需的所有樣式、客戶端代碼和標記。
當用戶單擊某些內容或頁面呈現(xiàn)從數(shù)據(jù)庫檢索的信息時，它正在與應用程序層進行交互。
應用層負責協(xié)調來自瀏覽器和/或來自用戶操作的信息到數(shù)據(jù)庫。有時，這包括將信息寫入數(shù)據(jù)庫（例如來自表單字段的信息）以及從數(shù)據(jù)庫讀取信息（例如檢索用戶的帳戶信息）。
就像表示層由不同的組件組成（例如樣式、JavaScript、標記等）一樣，應用程序層也可以由各種不同的組件組成，例如從數(shù)據(jù)庫讀取數(shù)據(jù)和向數(shù)據(jù)庫寫入數(shù)據(jù)所需的系統(tǒng)、清理信息、驗證信息以及執(zhí)行針對當前問題所特有的某些規(guī)則。
最后，數(shù)據(jù)庫層是存儲數(shù)據(jù)的地方。它可能由文件系統(tǒng)組成，可能由 MySQL 數(shù)據(jù)庫組成，也可能由第三方解決方案組成，例如“云中”的數(shù)據(jù)存儲（例如 Amazon S3 或類似的東西）。
都是抽象的
要理解的要點是，在軟件中，我們總是在處理某種程度的抽象。例如，我們談論數(shù)據(jù)存儲或數(shù)據(jù)庫層，但我們并沒有真正具體化。應用層和表示層也是如此。
- 我們是在談論具有多個表的關系數(shù)據(jù)庫，還是在談論云存儲？
- 我們將使用哪種數(shù)據(jù)訪問層連接到應用程序層來與數(shù)據(jù)庫通信？
- 我們在前端使用哪些框架和語言？普通 JavaScript、jQuery、Knockout.js？ CSS 預處理器 – LESS 或 Sass 怎么樣？
顯然，我們現(xiàn)在并不打算提供這些問題的答案，但重點是所有 Web 應用程序都包含類似的組件，但每個組件的詳細信息因項目而異。
WordPress 的組件
作為一個 Web 應用程序本身，WordPress 是各種技術如何組合在一起形成 Web 應用程序的完美示例：
- 數(shù)據(jù)庫層是MySQL數(shù)據(jù)庫。
- 應用層（有些人會認為是 WordPress 本身）是用 PHP 編寫的，處理許多讀取和寫入數(shù)據(jù)存儲的核心操作，同時為開發(fā)人員提供 API 以進一步利用它。
- 表示層使用基本的CSS（至少目前如此）、HTML（一些主題現(xiàn)在使用HTML5）、jQuery，并且部分儀表板使用Backbone.js。
這就是 WordPress 架構，但是我們想要在應用程序之上構建的項目又如何呢？他們如何遵循相同的架構？
好吧，請記住 WordPress 是一個基礎 – 而不是一個框架 – 因此我們默認受到 WordPress 架構的影響。這并不意味著在某些情況下我們不能引入自己的庫，但它確實會影響我們應用程序和項目的構建方式。
稍后我們將更多地討論庫、可擴展性等，但首先，重要的是要注意，在當今時代，MVC（以及 MVVM 和模型、視圖等的其他變體）范例風靡一時，但 WordPress不遵循這一慣例。
對于為什么這可能是好事或壞事，存在著支持和反對的爭論，但這不是這篇文章的目的。相反，值得注意的是 WordPress 使用事件驅動模式，而不是模型視圖控制面板。
為此，值得了解事件驅動模型的工作原理，以便您清楚地了解 WordPress 掛鉤的工作原理，以及如何將您的思維從 MVC 或您使用的任何其他范式轉變使用、WordPress 如何管理其信息。
事件驅動意味著什么？
在查看事件驅動應用程序的示例之前，讓我們回顧一下遵循 MVC 范例的含義。
- 首先，視圖用作演示。用戶查看信息并與用戶界面交互。
- 接下來，控制器協(xié)調模型和視圖之間的信息。它們響應用戶操作，并從模型中檢索信息以傳輸?shù)揭晥D中。
- 之后，模型代表數(shù)據(jù)庫中的數(shù)據(jù)。這可以通過多種方式完成，但最流行的方法之一是將數(shù)據(jù)庫中的數(shù)據(jù)映射到對象關系模型，以便數(shù)據(jù)以對象的格式表示。
整個MVC模型如下所示：
MVC圖標題>
現(xiàn)在，事件驅動的應用程序可以具有一些相同的組件 – 也就是說，它們可以具有視圖和模型或視圖和數(shù)據(jù)對象 – 但它們不一定具有協(xié)調從前端到后端的信息的控制器后端。
相反，事件驅動編程的工作前提是“某件事發(fā)生了”。因此，在 WordPress 行話中，操作 被命名為“操作”（當然，我們也有過濾器，但我將立即介紹這些內容）。
WordPress 提供了鉤子，這些鉤子實際上是執(zhí)行中的點，我們可以在其中引入自己的功能，以便 WordPress 識別“當此事件發(fā)生時，我需要觸發(fā)這些函數(shù)”，其中這些函數(shù)被定義為我們提供的任何內容。
事實是，過濾器的工作方式相同，但目的不同。簡而言之，過濾器是用于在返回應用程序執(zhí)行之前以某種方式操作數(shù)據(jù)（例如附加、前置、刪除或更新內容）的操作。
那么這看起來像什么？
沒什么特別復雜的，對吧？
那么我們的新架構是什么？
本文的要點主要是讓我們思考事件驅動編程以及如何協(xié)調我們專門在 WordPress 上構建 Web 應用程序的工作。
也就是說，我們必須根據(jù)事件或“發(fā)生了一些事情”的事實來思考，這樣我們才能知道何時適當?shù)夭迦胛覀冏约旱男袆印Ｎ覀儗⒃谙乱黄恼轮懈敿毜赜懻撨@一點，但我希望你們從這篇特定文章中學到的要點是，僅僅因為某些東西不是 MVC（或者任何下一個流行的范例） ）并不意味著它不適合應用程序開發(fā)。
每種模式和架構都為我們提供了優(yōu)點和缺點，所有這些都有助于成功構建 Web 應用程序。
下一個…
在本系列的下一篇中，我們將更詳細地了解掛鉤如何在 WordPress 上構建 Web 應用程序中發(fā)揮重要作用，然后我們將開始研究 WordPress 提供的一些功能 -使其成為某些類型（并非所有類型）網(wǎng)絡應用程序的可靠選擇。
