L'explication trouvée sur Internet est de faciliter le changement de base de données et d'éviter d'écrire du SQL. Je ne comprends pas très bien ces deux éléments.
Le premier est que changer de base de données est similaire au passage de MySQL à SQL Server. Mais tant que la structure des tables est la même, il n'est pas nécessaire de modifier le SQL natif. et constructeur de requêtes.
Deuxièmement, évitez d'écrire du SQL long, le constructeur de requêtes peut également le faire
En ce qui concerne la différence entre le constructeur de requêtes et ORM, je crois comprendre que le constructeur de requêtes est une classe qui génère du SQL, tandis que ORM est une classe qui correspond à une table et les champs sont mappés à des variables membres. J'ai une autre question. S'il y a beaucoup de tables et de champs, la classe ORM ne serait-elle pas très verbeuse ? Veuillez me corriger là où ma compréhension est fausse.
$user = DB::table('users')->where('name','Laravel')->first();//constructeur de requête laravel
$posts = Post::where('id','<',3)->orderBy('id','desc')->take(1)->get();//laravel orm 
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Vous avez raison, s'il y a beaucoup de tables et de nombreux champs, alors la classe ORM sera très verbeuse.
L'essence de l'ORM est de mapper les tables de base de données et les relations entre les tables avec les objets et les relations d'objets. Il convient de noter que bien que cette relation de mappage soit bidirectionnelle, il existe certains problèmes dans le sens Objet->RDB. Certaines limitations, c'est. car la description des entités par RDB n'est pas aussi riche que la description des entités par Object.
Explication sur les deux raisons que vous avez évoquées :
Il est pratique de changer de base de données. Personnellement, je pense que même si ORM propose une telle fonctionnalité, ce n'est pas courant car il est rare de changer de base de données dans des projets réels.
Évitez d'écrire du SQL. C'est une raison importante pour utiliser ORM, car les programmeurs sont paresseux et ne veulent pas apprendre SQL (même si SQL est facile à apprendre), et c'est aussi une raison importante pour laquelle ORM a été produit à l'origine.
Pour donner une réponse simple, ORM est l'abréviation d'objet Relational Mapping. L'objet est un objet, le relationnel est une relation et le mappage est un mappage. Le mappage objet-relationnel semble assez abstrait, et oui, c'est un concept abstrait. Du point de vue de la syntaxe de programmation, lors de l'exploitation spécifique d'objets métier, vous n'avez plus besoin de gérer des instructions SQL complexes, il vous suffit d'exploiter simplement les propriétés et les méthodes des objets.
Alors répondez à vos deux questions
Premièrement, il existe de nombreuses différences entre mysql et sqlserver. Les fonctions commençant par mysql_ que vous utilisez dans le programme ne seront pas reconnues par sqlserver. Alors comment migrer sans changer le code ?
Deuxièmement, ORM contient les relations de mappage suivantes, pas seulement le mappage entre les tables et les classes.
Mappage des classes et des tables dans la base de données : Chaque table de la base de données correspond à une classe dans le langage de programmation
Mappage des objets et des enregistrements dans les tables : Une table dans une base de données relationnelle peut avoir plusieurs enregistrements, et chaque enregistrement correspond à une instance d'une classe
Le mappage entre les attributs de la classe et les champs de la table dans la base de données : Les types de données des champs de la table dans la base de données et les types d'attributs dans la classe correspondent également un à un