J'ai toujours eu l'impression que beaucoup de ce qui sous-tend le "vote de confiance" a été une tentative d'utilisation de l'EF comme si c'était un NHibernate clone. Il n'est pas, et même en EF 4 la tentative d'utilisation de l'EF comme s'il s'agissait d'un NHibernate knockoff est probablement à l'échec, même si vous pouvez obtenir un peu plus loin avant d'échouer. Comme un exemple trivial, la plupart des gens utiliser LINQ dans NHibernate sur une base minimale, si à tous, alors que je ne pense pas que vous puissiez être productif en EF à tous , sauf si vous utilisez LINQ assez fortement.
D'autre part, j'ai assez bien réussi à l'utilisation de l'EF 1 sur ses propres termes, et ont réussi à ne pas autoriser les demandes que font les gens dans les messages blog pour obtenir de la manière de le faire fonctionner pour moi. J'ai hâte d'utiliser de nombreuses fonctionnalités nouvelles en EF 4, mais je serais heureux de travailler sur un bien structuré EF 1 projet en tout temps. (D'ailleurs, je suis heureux de travailler avec NHibernate, trop, et de ne pas critiquer, de ne pas agir comme l'EF.)
Donc, je suis en train de suggérer, de manière un peu délicat de sorte que, avant que vous pouvez décider si "les demandes formulées dans la motion de censure sont toujours valables (dans .NET 4)..." vous devez d'abord décider si ces demandes ont été toujours valable pour vous et la façon dont vous travaillez. Si votre compréhension personnelle de l'O/R est câblé à NHibernate, puis EF 4 est probablement encore va sembler deuxième taux pour vous. Si, d'autre part, vous êtes prêt à apprendre l'EF façon de travailler, alors même probablement EF 1 semble mieux que vous avez entendu.
Pour remédier à la "non-confiance" réclamations directement, et d'examiner à la fois de leur substance et ce qui a changé en EF 4:
IMMODÉRÉ DE CONCENTRER LES DONNÉES DE L'ASPECT DES ENTITÉS CONDUIT À LA DÉGRADATION DE L'ENTITÉ ARCHITECTURES:
C'est une mauvaise compréhension de l'Entité Cadre du modèle de données d'entité. (Ou, une différence d'opinion, si vous préférez.) Mais de toute façon, c'est une fonction, pas un bug. Entity Framework est conçu autour de le cas plus général des services de données, pas seulement O/R de la modélisation, en particulier. Mettre des comportements sur les entités retournées à partir d'un service de données conduit à une CORBA style de catastrophe. Contrairement à l'Orm où vous êtes, à un certain degré, coincé avec quelque soit le type sort de l'ORM blackbox, avec le modèle d'Entity Framework, vous êtes attendus du projet sur les types d'entreprise. Dans ce cas, le cartographié les types d'entité ne sera plus jamais matérialisé.
C'est une différence de fond entre le modèle d'Entity Framework et de nombreux autres Orm. Personnellement, je trouve la séparation d'affaires des comportements à partir de mappage O/R pour être tout à fait un peu plus propre que de regrouper ensemble. Vous n'avez pas à être d'accord avec cette idée, mais c'est clairement une décision de conception, pas d'un oubli.
L'EXCÈS DE CODE NÉCESSAIRES POUR FAIRE FACE À L'ABSENCE DE CHARGEMENT PARESSEUX:
L'EF 4, pour le meilleur ou pour le pire, a lazy loading.
Je dis "pour le meilleur ou pour le pire" parce que le chargement paresseux, il est très facile de générer un excès de requêtes de base de données. Il fonctionne très bien aussi longtemps que vous gardez un œil attentif sur ce qui se passe sous le capot, mais la plupart des gens ne font pas cela. Je trouve projection à être une meilleure alternative pour le chargement paresseux, désireux de chargement, ou le chargement explicite la plupart du temps.
Encore, il ya des moments où le chargement paresseux est pratique. Je suis donc heureux de le voir s'ajouter en EF 4.
PARTAGÉ, MODÈLE CANONIQUE CONTREDIT DE LOGICIELS MEILLEURES PRATIQUES:
Il est difficile de savoir quoi faire de même, comme le texte qui l'accompagne n'est même pas cohérent de l'anglais, par exemple:
Les sujets aux pannes modèle canonique approche n'était pas difficile pour un manque d'élaborer l'outillage, le long de la lignes de l'Entity Framework.
Cette section semble suggérer que l'Entity Framework impose un certain type d'exigence, ou au moins une forte orientation vers l'aide d'un seul modèle de données canonique d'un système complexe. Je ne suis pas sûr que je suis d'accord, mais c'est difficile à dire, étant donné l'absence d'un exemple dans cette section. Je vais donc vous raconter mes propres préjugés sur le sujet, et vous pouvez être d'accord ou pas d'accord avec moi:
C'est souvent une erreur d'utiliser un seul modèle pour un système plus large, en fonction de la taille du système est en réalité. Rien dans le Cadre de l'Entité exige l'utilisation d'un modèle unique, cependant. D'autre part, le Cadre de l'Entité, en particulier dans la version 1, ne pas sortir de sa façon de faire, il est facile de combiner plusieurs modèles.
Maintenant, une seule grande application pour un système complexe peut être aussi grand d'une erreur, car un seul modèle de données. Donc, il ne serait pas correct pour Entity Framework pour le rendre facile à combiner beaucoup de petits modèles dans une trop grande application; ce serait tout simplement de remplacer un problème par un autre.
D'autre part, je pense qu'il fait sens pour le rendre facile la construction d'un grand système de services cloisonné dans une manière qui corresponde au domaine du problème. Je pense que les services de données WCF, une technologie distincte de l'Entity Framework, mais celle qui prend en charge le Cadre de l'Entité très bien, sont utiles pour cela.
Je pense que l'Entity Framework pourrait, dans une version future, le rendre plus facile à combiner deux ou trois modèles dans une seule application si nécessaire. Vous pouvez le faire maintenant, mais il y a quelque travail manuel impliqués. Mais comme je l'ai dit ci-dessus, je ne veux pas de "résoudre" un problème d'un trop grand modèle de données en faciliter/encourager la création d'une trop grande demande.
MANQUE DE PERSISTANCE IGNORANCE EST LA CAUSE DE LA LOGIQUE D'ENTREPRISE À ÊTRE PLUS DIFFICILE À LIRE, ÉCRIRE ET MODIFIER, CAUSANT DE DÉVELOPPEMENT ET LES COÛTS DE MAINTENANCE D'AUGMENTER À UN EXAGÉRÉE DE TAUX:
Cette section contient des allégations qui me semble erronée:
Entity Framework encourage l'Anémie du Modèle du Domaine de l'anti-modèle en décourageant l'inclusion de la logique métier dans les classes d'entité.
Voir ci-dessus. Je pense que le travail de la des types d'entité est à la carte entre de l'espace relationnel dans l'espace objet. Par le Principe de Responsabilité Unique, ces types ne doivent être modifiés que lorsque leur seule changements d'emploi. Si les processus d'affaires de changer, alors c'est une responsabilité sans rapport avec mappage O/R. Peut-être les limites d'autres Orm imposer une barrière technique sur la séparation de ces responsabilités. C'est bien de plier les règles lors de la technologie dicte, si le coût de la conception de la pureté est excessif. Mais je suis fortement en faveur de l'approche du comportement-moins de types d'entité.
Dans son état actuel, EF les classes d'entité ne peuvent pas être efficacement unité testée indépendamment de la base de données.
C'est tout simplement faux. Celui qui a écrit cela n'a pas compris de quoi ils parlaient. Aucun de nos tests unitaires toucher la DB, jamais, et beaucoup d'entre eux concernent l'EF.
Dans la mesure où la substance du titre de cette section, il y a un changement pour EF 4. Il est maintenant possible d'avoir entièrement ignorant la persistance des types d'entité, si cela aide votre conception. Cependant, à partir de la version la plus ancienne de l'Entité Cadre sur les mots, vous avez été en mesure de projeter sur POCOs. Donc, la persistance de l'ignorance a toujours été disponible quand il le faut. Ayant l'ignorance de la persistance des types d'entité se permet le suivi des modifications avec un ignorant la persistance de l'objet. Qui peut être utile dans certains cas. Mais il est sensiblement plus petit sous-ensemble de cas que de fausses allégations sur les tests unitaires, ce qui réduit l'impact du point le document fait par beaucoup.
EXCESSIVE DES CONFLITS DE FUSION AVEC LA SOURCE DE CONTRÔLE DANS DES ENVIRONNEMENTS D'ÉQUIPE:
La fusion est XML que réellement difficile? Si oui, on devrait peut-être regarder dans un nouvel outil de fusion. Je ne trouve pas cette problématique.
Cependant, il y a un véritable problème ici, bien que, encore une fois, c'est beaucoup plus étroit que le document affirme. Plutôt que de me répéter, je vais juste vous orienter vers mon post sur le sujet.
En EF 4, on peut utiliser le code-première les modèles plutôt que XML des modèles afin de diviser un modèle dans beaucoup de différents fichiers.
