了解ORM-object relational mapping：優點、缺點和類型

Home >> Blog >> 了解ORM-object relational mapping：優點、缺點和類型

了解ORM-object relational mapping：優點、缺點和類型

使用物件導向程式設計 (OOP) 語言和資料庫的挑戰之一是將程式碼與資料庫結構對齊的複雜性。對象關係映射 (ORM)是一種在語言和資料庫之間創建一層的技術，可幫助程式設計師在沒有 OOP 範式的情況下處理數據。

OOP 開發人員面臨的挑戰是需要理解結構化查詢語言 (SQL-Structured Query Language) 並進行程式設計，以便將他們的應用程式連接到SQL 資料庫。了解 SQL 的開發人員可以編寫數據訪問程式碼。這種原始 SQL 程式設計可能非常耗時，因為它需要開發人員提取程式碼字符串的數據元素。SQL 查詢構建器向 SQL 程式碼添加了一個抽象層，以提供有關數據的更多資訊。但是，開發人員仍然需要理解和編寫 SQL。

ORM 很受歡迎，同時也有爭議。ORM 的擁護者聲稱它們可以提高生產力、改進應用程式設計、重用程式碼並隨著時間的推移維護應用程式。根據批評者的說法，ORM 的一個負面方面是性能。本文將概述 ORM，將它們與 SQL 工具進行比較，並回顧這些工具的優缺點，以便您決定 ORM 是否有助於或損害您的資料庫應用程式開發工作，特別是設計SEO頁面解析程式時的選擇。

什麼是 ORM？

對象關係mapping在關係資料庫和面向對象程式語言之間提供了一個面向對象層，而無需編寫 SQL 查詢。它標準化了接口，減少了樣板文件並加快了開發時間。

面向對象的程式包括許多狀態和程式碼，其格式難以理解和解釋。ORM 翻譯這些數據並創建結構化映射，以幫助開發人員了解底層資料庫結構。該映射解釋了對像如何與不同的表相關聯。ORM 使用此資訊在表之間轉換數據，並為關係資料庫生成 SQL 程式碼，以響應應用程式對數據對象所做的更改來插入、更新、創建和刪除數據。編寫完成後，ORM 映射將管理應用程式的數據需求，您無需再編寫任何低級程式碼。

ORM 是如何工作的？

ORM 創建具有高級抽象的面向對象程式的模型。換句話說，它在沒有程式碼底層細節的情況下形成了一層邏輯。映射描述了對象和數據之間的關係，而不知道數據的結構。然後可以使用該模型將應用程式與管理數據活動所需的 SQL 程式碼連接起來。這種“管道”類型的程式碼不必重寫，為開發人員節省了大量時間。

ORM 的類型

ORM 採用兩種不同的策略：活動記錄模式和數據mapping模式。

活動記錄模式

此策略將數據映射到程式碼中的對象結構中。您可以使用程式碼中的類和結構來管理數據。這種方法存在問題，因為資料庫結構與程式碼緊密相連，難以刪除資料庫並將其遷移到不同的應用程式。

數據mapping模式

數據mapping模式試圖將對像中的業務邏輯與資料庫分離。這種分離可以使更改資料庫和使用相同的程式邏輯變得更加容易。

ORM 與 SQL

開發人員可以使用原始 SQL 程式碼編寫應用程式和資料庫之間的直接接口。大多數關係資料庫都支持 SQL 來構建數據接口和應用程式。它很穩定，而且自從 1970 年代以來就一直在使用 SQL，它有很好的文檔記錄和支持。程式設計師對其與 SQL 的數據接口保持大量控制。它需要做很多工作，但它比 ORM 抽象更靈活、更詳細。

使用 SQL 進行本機查詢

使用原始 SQL 也有其缺點。例如，開發人員負責資料庫程式碼的安全性。SQL 注入是一個問題，用戶輸入會影響數據狀態，從而導致應用程式和數據完整性出現問題。ORM 會清理程式碼，從而更容易避免這些問題。

SQL 查詢構建器

查詢構建器在原始 SQL 之上添加了一層抽象，而不掩蓋所有底層細節。構建器形式化查詢模式並向添加轉義項的方法或函數添加，以便於應用程式集成。他們添加了一個模板層，以幫助開發人員了解同一程式設計應用程式中的資料庫結構。模板構建器仍然需要開發人員了解資料庫結構，要求他們了解 SQL。

對象關係映射的優點

ORM 工具在 OOP 開發人員中很受歡迎，因為它們最大限度地減少了將資料庫連接到應用程式所需的 SQL 知識量。ORM 還會自動生成 SQL 程式碼，讓您專注於生成業務邏輯。使用與對象相關的mapping來管理應用程式和資料庫之間的接口有四個顯著的好處。

生產率

編寫數據訪問程式碼非常耗時，並且不會為應用程式的功能增加很多價值。它本質上是程式碼的管道。使用像 ORM 這樣自動生成數據訪問程式碼的工具可以節省大量開發時間，但不會為應用程式增加價值。在某些情況下，ORM 可以為應用程式編寫 100% 的數據訪問程式碼。ORM 還可以幫助您跟踪資料庫更改，從而使將來更容易調試和更改應用程式。

應用程式設計

編寫良好的 ORM 將實現設計模式，以迫使您使用最佳實踐進行應用程式設計。如果使用 ORM 來管理數據接口，則無需提前創建完美的資料庫模式。您將能夠輕鬆更改現有界面。將資料庫表與程式碼分開還允許您為不同的應用程式切換數據。

程式碼重用

重用數據的一種方法是創建一個類庫來生成一個單獨的動態鏈接庫 (DLL)。您可以創建新應用程式而無需複制數據訪問程式碼。

減少測試

由於 ORM 生成的程式碼已經過良好測試，因此您無需花費太多時間來測試數據訪問程式碼。相反，您可以專注於測試業務邏輯和程式碼。

對象關係映射的缺點

ORM 是許多應用程式的優秀工具，但一些開發人員發現將 ORM 用於數據訪問應用程式時存在一些缺點。這些問題似乎與應用程式的複雜性有關。對於簡單的應用程式，具有高級別的抽像有助於開發過程。但是當應用程式很複雜時，抽象會涵蓋解決數據相關問題所需的許多細節。

表現

OOP 開發人員的一個常見抱怨是 ORM 生成的額外程式碼。添加的程式碼會降低應用程式的性能並使其更難維護。一個設計良好的 ORM 應該能夠在不影響應用程式速度的情況下創建高質量的程式碼。

需要知道 SQL

高級抽象並不總能生成最好的 SQL 程式碼，開發人員不能 100% 地依賴 ORM。您仍然需要了解 SQL 以及 ORM 生成的語法。

映射不良

ORM 有時會在數據表和對象之間創建不正確的映射。這些問題可能會導致應用程式問題並且難以識別。ORM 也鼓勵一對一的映射，即使業務應用程式很少有很多一對一的關係。

對架構和遷移的影響

寫得不好的 ORM 層通常會使改進數據模式變得具有挑戰性。它通常會限制您的選擇，並且根據 ORM，您的選擇可能會受到限制。如果您的 ORM 不支持遷移，那麼在 OOP 中編寫遷移比在 SQL 中編寫遷移程式碼更複雜。一個編寫良好的 ORM 將包括促進未來資料庫遷移的工具。

流行的 ORM 概述

Prisma 2

Prisma 2是用於Node.js和 TypeScript的下一代開源 ORM 。Prisma 2 適用於 PostgreSQL、MySQL 和 SQLLite 資料庫。模塊包括 Prisma Schema、Prisma Client、Prisma Migrate 和 Prisma Studio。

Sequelize

Sequelize是一個基於 Promise 的 ORM，於 2011 年首次推出。它具有廣泛的文檔集，並且是 Node.js 的良好支持的 ORM。它支持 PostgreSQL、MySQL、MariaDB、SQLite 和 MSSQL。

類型ORM

雖然TypeORM可以與傳統的 JavaScript 一起使用，但它推薦使用TypeScript。它包括遷移、CLI 和應用程式數據模型的多種方式等功能。TypeORM 支持 ActiveRecord 和 Data Mapper 模式。

結論

編寫 SQL 程式碼以將關係資料庫附加到面向對象的應用程式可能是一項耗時的活動，對業務應用程式幾乎沒有價值。開發人員可以編寫原始 SQL 程式碼或使用 SQL 查詢構建器來改進流程，但這兩種方法仍然需要深入的資料庫知識和 SQL 程式設計能力。ORM 通過創建高度抽象的數據模型和自動生成 SQL 程式碼來提高生產力。這些工具還可以更輕鬆地將資料庫與程式邏輯分開，從而為開發人員提供更大的靈活性。但 ORM 也有批評者。常見的抱怨包括性能下降、額外的程式設計和糟糕的映射，具體取決於 ORM 質量。

在承諾使用 ORM 來加速 OOP 開發過程之前，開發人員需要做足功課。有幾個開源和商業工具可用。由於這些工具已經使用了很多年，因此它們有很好的文檔記錄並得到了廣泛的開發社群的支持。