Quand ne pas utiliser Entity Framework

.net architecture c# entity-framework

Question

J'ai joué avec l'EF pour voir ce qu'il peut gérer. De plus, de nombreux articles et messages expliquent les différents scénarios dans lesquels l’EF peut être utilisé, mais si l’on manque quelque peu le côté "con". Ma question est la suivante: dans quels types de scénarios devrais-je rester à l’écart de Entity Framework ?

Si vous avez de l'expérience dans ce domaine, dites-moi quels scénarios ne fonctionnent pas bien avec l'EF. Parlez-moi de certains des inconvénients que vous avez connus lorsque vous auriez souhaité choisir une technologie différente.

Réponse acceptée

Je suis aussi juste en train de «jouer», et bien que je m'inquiète du manque d'agnosticisme inhérent à la persistance, j'étais sûr qu'il y aurait un «contournement».

En fait, pas même une solution de contournement dans une architecture à plusieurs niveaux.

WCF + EF

Si j'ai bien lu l' article , je ne vois pas de problème de sérialisation des entités sur le réseau (avec WCF) et l'ignorance de la persistance ne pose pas de problème.

C'est parce que j'utiliserais principalement PI pour les tests unitaires.

Le test unitaire est possible! (je pense)

Dans ce système, nous pourrions simplement utiliser un service fictif (en encapsulant l'appel au service dans une classe basée sur une autre interface pouvant être produite à partir d'une usine, par exemple). Cela testerait NOTRE code de présentateur (il n'est pas nécessaire de tester en bloc l'EF / DAL - c'est le travail de Microsoft!). Bien entendu, des tests d'intégration seraient toujours nécessaires pour obtenir une confiance totale.

Si vous voulez écrire dans une base de données séparée, cela se fera dans la couche DAL, facilement obtenue via le fichier de configuration.

Ma valeur Tuppence

Mon opinion - décidez-vous vous-même de l'EF et ne vous laissez pas rebuter par la tristesse qui règne autour de lui. Je suppose que cela va durer un certain temps et que MS va réparer les erreurs dans l’année à venir. PI entre définitivement selon Dan Simmons.

EDIT : Je viens de me rendre compte que j’ai sauté le flingue et qu’un bon politicien n’a pas répondu à la question posée. Oops. Mais je laisserai ceci au cas où quelqu'un le trouverait utile.


Réponse populaire

Le Vote of No Confidence énumère plusieurs faux pas et / ou éléments de fonctionnalité manquants aux yeux de ceux qui pensent connaître les fonctionnalités et leurs implémentations, qui conviennent aux frameworks ORM / Datamapper.

Si aucun de ces problèmes ne vous préoccupe beaucoup, alors je ne vois pas pourquoi vous ne devriez pas l'utiliser. Je n'ai pas encore entendu dire que c'est un gâchis buggy qui explose à gauche et à droite. Toutes les mises en garde contre cela sont philosophiques. Je suis d'accord avec le vote de censure, mais cela ne signifie pas que vous devriez. Si vous aimez le fonctionnement de EF, alors foncez. En même temps, je vous conseillerais au moins de lire le vote de censure et d’essayer d’obtenir une compréhension rudimentaire de chacune des questions afin de prendre une décision éclairée.

En dehors de cela et au cœur de votre question - Vous devez garder un œil sur le SQL généré pour pouvoir apporter des modifications avant qu'un problème de performance ne soit mis en production. Même si vous utilisez des procs sur le backend, je chercherais quand même des scénarios dans lesquels vous pourriez frapper la base de données trop souvent, puis retravaillerez vos mappages ou vos scénarios de récupération en conséquence.



Related

Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow