Lors de la conception d'ORM, quelle est la meilleure approche pour représenter la relation, en termes de performances?

Question

Lors de la conception d'ORM, quelle est la meilleure approche pour représenter la relation, en termes de performances? Je veux dire, sur les deux suivants, quelle approche est la meilleure considération de la performance?

class Employee 
{ 
    int ID { get; set; } 

    String Name { get; set; } 

    int DepartmentID { get; set; } //This approach uses DepartmentID 
} 

--- OU ---

class Employee 
{ 
    int ID { get; set; } 

    String Name { get; set; } 

    Department Department { get; set; } //This approach uses Department class 
} 

De mon point de vue, la seconde approche est agréable. C'est aussi orienté objet. Et cela devrait être l'objectif principal de ORM; pour convertir la relation de SGBDR en objet orienté. Mais en faisant cela, nous serions obligés de charger l'ensemble de l'objet Department dans un objet personnel, même si ce n'est pas obligatoire.

Comment devriez-vous représenter ou quelle devrait être la meilleure approche selon vous?

Answer 1

La plupart des structures ORM gèrent le second cas avec des performances équivalentes au premier cas. Prenant Hibernate comme exemple de référence ici, ils vous diraient en termes clairs de ne jamais faire la première option. Ils sont un peu sarcastiques à ce sujet, en fait.

En fait, je crois que la première option ne serait techniquement pas considérée ORM, puisque les relations sont traitées au niveau ID dans votre code POO.

Hibernate (comme la plupart des autres) a un chargement paresseux, ce qui signifie que vous pouvez charger votre employé et il ne cherchera pas le département. Mais si vous dites employee.getDepartment(), à ce moment-là, allez à l'instruction select simple pour obtenir les données du département. Cela peut également être configuré au moment du mappage ou de l'heure de la requête. Par conséquent, si vous savez que vous aurez besoin du département, vous pouvez enregistrer le second appel SQL en lui demandant de récupérer à la fois Employee et Department. une requête de jointure.

Consultez le "Small Primer on Fetch Strategies" de Hibernate pour plus d'informations.

Answer 2

ce n'est pas tellement une différence de performance, c'est en fait un seul est plus facile à mettre en œuvre que l'autre.

Answer 3

Vous oubliez que des articles connexes peuvent être chargés paresseusement. En d'autres termes, lorsque vous créez votre objet Employee, il n'est pas nécessaire de remplir le champ Department. Cela peut être rempli lorsque l'accesseur get est appelé.