ORM local contre DataTables?

https://stackoverflow.com/questions/271806

06-07-2019
|

Question

Ceci est une simplification du problème (il y a beaucoup de façons de faire les choses), mais parmi les applications qui ont besoin de communiquer avec une base de données, j'ai généralement observé l'un des deux modèles suivants:

Mappage relation-objet (ORM), où (généralement) chaque table de la base de données a un "wrapper de ligne" " correspondant classe dont les propriétés publiques correspondent aux colonnes de la table. Parfois, ces classes récupèrent aussi automatiquement les informations associées, de sorte que les colonnes de clé étrangère puissent être exposées et affichées en tant que données associées (plutôt que uniquement les valeurs PK).
DataTables (et / ou DataSets), où les données sont extraites du serveur en tant que DataTable et utilisées sous cette forme (même dans l'interface utilisateur).

L'une des principales différences entre les deux approches est que ORM vous permet de référencer des champs fortement typés dans votre code, comme suit:

Person bob = new Person();
bob.FirstName = "Bob";
collectionPeople.Add(bob);

alors qu'avec l'approche DataTable, votre code ressemblerait à quelque chose comme:

DataRow newrow = datatablePeople.NewRow();
newrow["FirstName"] = "Bob";
datatablePeople.Rows.Add(newrow);

Dans ce cas, l'approche ORM bénéficie de la vérification à la compilation, contrairement à l'approche DataTable. D'autre part, le DataTable (et le DataSet) sont des structures de données déjà écrites qui représentent un excellent travail de représentation directe des données relationnelles. Par conséquent, le code qui les utilise peut généralement être implémenté plus rapidement. De plus, le code qui utilise DataTables peut être facilement compris et modifié par d’autres; Les systèmes ORM de production locale (et souvent COTS) offrent souvent un accès supplémentaire à la base de données "sous le capot". pour renseigner des clés étrangères, etc., ce qui peut créer des problèmes pour les non-conscients.

Alors, quelle approche préférez-vous et pourquoi?

La solution

Datatable sera certainement conceptuellement plus simple à utiliser avec les données. Et c'est dépourvu d'idiomes parfois peu naturels que vous trouvez dans ORM. (interroger un enregistrement dans la mémoire locale avant de le mettre à jour; les jointures sont des pointeurs; la valeur de la clé est elle-même un pointeur; par conséquent, l'ajout d'un enregistrement nécessite le chargement de l'enregistrement parent)

Les gros avantages pour ORM sont ...

1) il écrit le sql pour vous, vous n'avez donc pas à écrire de sql pour faire du crud de base. Bien sûr, écrire des énoncés plus complexes doit être fait dans un sous-langage moins puissant (c'est-à-dire hql)

2) L’autre grand avantage de ORM est que lorsque vous obtenez des résultats, il les mappe en objets de valeur, sans écrire un tas de code pour mapper les valeurs et gérer la conversion de type.

Si vous avez de bonnes compétences en SQL mais que vous voulez un avantage 2 couvert, j'irais avec ibatis

Autres conseils

Je privilégie la méthode DataTables, car je suis vieux, fatigué et sceptique face aux modes comme Subsonic et Linq.

Au-delà de cela, lorsque vous travaillez avec un ORM, vous minimisez généralement ce que vous faites en SQL. Vous ne mettez pas beaucoup de logique dans le code SQL et vous ne créez pas plusieurs instructions SQL de manière à effectuer plusieurs opérations en une fois dans la base de données. Par conséquent, vous avez tendance à consulter la base de données plus souvent, ce qui constitue un gros problème de performances.

À l'aide de jeux de données, je peux faire quelque chose comme:

sélectionnez col1, col2 ... dans la table1

sélectionnez col1, col2 ... dans la table2
sélectionnez col1, col2 ... dans la table3

puis effectuez UN SEUL voyage dans la base de données pour obtenir les trois ensembles de données, en utilisant les Tableaux [0], Tableaux [1], Tableaux [2] pour les référencer. Cela fait une très grande différence dans les performances.

Peut-être qu'un jour l'interaction avec la base de données sera si rapide qu'il ne servirait à rien de compiler le code SQL, mais ce jour n'est pas encore arrivé. Quand cela arrivera, je passerai à ORM, mais d'ici là, je souhaite que mon code soit un peu plus laid en échange de performances. Ce n’est pas amusant pour les utilisateurs d’utiliser une application lente.

Enfin, j'aime SQL. Je suis bon en SQL. Vraiment bien. Je ne veux pas passer mon temps à chercher comment co-autoriser Linq à émettre le code SQL que je veux. Cela ralentirait les performances de MES .

Vous pouvez combiner les deux approches mentionnées à l'aide des DataSet fortement typés .

Il est possible de les ajouter à un projet Visual Studio via "Ajouter un nouvel élément". dialogue " modèle DataSet " puis utilisez visual Dataset Designer (il édite le fichier XSD en coulisse).

Il existe un autre article sur le sujet.

Dans .Net, les jeux de données fortement typés présentent les avantages que vous attribuez à ORM: valeur du typage renforcé dans l'EDI et Intellisense,

Les TableAdapters créés dans Visual Studio écriront tout votre code CRUD SQL pour vous. Vous mettez votre logique métier dans le C # (ou autre langue) et non dans le SQL.

Je pense que le modèle de données déconnecté proposé par les jeux de données s'avère plus efficace en pratique que le code SQL codé à la main typique. Cela conduit à des interactions de base de données non-bavardes dans lesquelles vous obtenez toutes les données de la table associée dans une seule requête. Et il prend très bien en charge le verrouillage optimiste (fournissant des exceptions DBConcurrency). L'ensemble de données suit également les insertions, modifications et suppressions de vos données, pour que vous n'ayez pas à le faire.

Les jeux de données fortement typés offrent également une navigation directe vers les données de table associées.

Une bonne référence sur les DataSets est

Programmation Microsoft & # 174; ADO.NET 2.0   Référence de base de David Sceppa

Editeur: Microsoft Press Pub Date:   17 mai 2006 Imprimer ISBN-10:   0-7356-2206-X Imprimer ISBN-13:   978-0-7356-2206-7 Pages: 800

+ tom

J'examinerais les avantages des objets de données par rapport à DataTables (une bibliothèque ORM sophistiquée n'est pas vraiment nécessaire, bien qu'elle puisse être agréable):

Conceptuellement propre. Vous êtes obligé d'appliquer les concepts OO à vos données. Il est plus facile de comprendre "ceci est une personne". par opposition à "la personne que je veux se trouve quelque part dans ce tableau".
Impose la séparation des préoccupations. Il est tentant d'intégrer les données contextuelles de l'interface utilisateur à un DataTable: pour une interface utilisateur, une personne avec une adresse principale se trouve dans le même enregistrement, pour une autre, une personne avec des informations de crédit dans le même enregistrement. Lorsque je travaille avec un modèle, je souhaite que ce modèle soit cohérent où que je le consomme.
Ne transformez les données qu'une seule fois. Dans les applications critiques que j'ai vues, il y a beaucoup de choses éparpillées partout:

if (row [" col "] == DBNull.Value || string.IsNullOrEmpty (row [& col;"] sous forme de chaîne)) ...

Je préfère vérifier cette condition une fois lorsque je remplis l'objet de données que de la vérifier partout où le DataTable est utilisé.
Plus facile au test unitaire. Si vous faites référence à un champ dans un objet de données qui n'existe pas, vous obtenez une erreur lors de la compilation. Si vous référencez un champ dans un DataTable qui n'existe pas, vous obtenez une erreur d'exécution.

Je crois que ORM peut vous rendre paresseux. Par exemple, il n'y a absolument aucune raison de renseigner un ensemble d'objets de données liés à partir de requêtes individuelles si ces objets sont toujours utilisés ensemble. Au lieu de cela, écrivez une requête volumineuse et efficace qui récupère toutes les données nécessaires, puis construit le graphe d'objet de données. Néanmoins, si vous gardez à l’esprit ses limites, vous épargnerez beaucoup de travail.

En relation: Comment convaincre mes collègues de ne pas utiliser les jeux de données pour le développement d’entreprise (.NET 2.0+) .

J'avais l'habitude d'utiliser DataSets au début des jours .NET, puis de commencer à utiliser des DataSets typés. Au fil du temps, nous avons constaté que la mémoire laissée par DataSet était très élevée et qu'il n'était pas logique d'utiliser des objets non gérés pour chaque tâche simple.
Par conséquent, nous avons conclu que les DTO / POCO sont un meilleur choix et ont commencé à utiliser NHibernate et iBatis.
Mes développeurs moyens (ou inférieurs à la moyenne) les ont trouvés complexes et difficiles à utiliser (sans jeu de mots).
J'ai donc créé un ORM développé à la maison XmlDataMapper beaucoup plus facile à utiliser que les ORM complexes existants.

Pour intégrer XmlDataMapper, il vous suffit de suivre 4 étapes simples

Créer une entité commerciale / DTO pour les tables
Créez un fichier XML avec les informations de mappage entre la table et le DTO.
Spécifiez le fichier DTO et XML dans la configuration.
Appelez simplement DTOConverter.Convert (dataReader) et d’autres méthodes similaires pour convertir votre enregistrement de base de données en DTO / entité commerciale

J'avais l'habitude d'utiliser simplement un datareader pour lire les champs sur mon objet à l'aide de GetString, GetInt, etc. puis passé dans une classe de service qui analyse la table sur un objet.

Je n’ai jamais vraiment aimé les outils ORM, ils étaient toujours encombrants et difficiles à maintenir, mais je n’ai pas encore eu la chance de jouer avec LINQ, donc mon opinion peut changer.

Je trouve que je suis capable de développer moins de code et de tester mon code mieux en utilisant un ORM que DataSets / DataTables. J'utilise actuellement LINQ-to-SQL et enveloppe une couche mince autour du code généré par le concepteur via des classes partielles comme mon ORM. La couche mince me permet essentiellement d'ajouter des autorisations basées sur les rôles et augmente la testabilité du code en refacturant les interfaces et en utilisant l'injection de dépendance pour spécifier le contexte des données (afin que je puisse le simuler pour d'autres tests).

J'ai fait les deux. J'ai écrit mon propre ORM autour de DS / DT, DS / DT fortement typé, etc., puis je suis passé à LINQ et je ne vais pas revenir en arrière. Je pourrais éventuellement passer à quelque chose comme NHibernate, Entity Framework ou autre chose, mais pour le moment, ma solution LINQ offre à peu près tout ce dont j'ai besoin et est beaucoup plus simple que mes anciennes solutions.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow