Il y a quelques années, nous avons développé une grande application ASP.NET (C # / .NET 3.5) qui devait être "moteur de base de données" non dépendant (ce qui signifie que cette application pourrait utiliser SQL Server, Oracle, MySQL ... en tant que moteur DB). Pour cela, nous avons utilisé le bloc d'accès à la bibliothèque d'entreprise 4.1.
Mais maintenant, comme nous sommes sur une phase de «performance / d'amélioration de l'évolutivité», nous réfléchissons à la mise à niveau de la technologie ou à la ré-conception de nos fondations d'applications.
Donc, la question est la suivante: y a-t-il un avantage pour passer au cadre d'entité? EF conservera-t-il notre critère de "moteur de base de données" non dépendant? Ou devrions-nous conserver notre implémentation ENTLIB DAAB, mais la mise à niveau de la dernière version (5.0)?
merci
3 Réponses :
Il existe un certain nombre de fournisseurs d'EF pour Oracle ( Devart DotConnect pour Oracle , datadirect ) et mysql ( Devart DotConnect pour MySQL , MySQL Connector / Net ) et Microsoft fournit un fournisseur de cadre d'entité pour SQL Server. Il ne devrait donc pas y avoir de problèmes avec l'indépendance de la base de données.
J'apprécie la réponse, mais de la FAQ: Vous devez divulguer votre affiliation dans vos réponses .
Le problème le plus important qui se déplace entre eux ne concerne pas l'indépendance de la base de données, c'est que le modèle d'utilisation est fondamentalement différent. Le bloc d'accès aux données (DAAB) est principalement une enveloppe de commodité autour de Ado.net. Il est plus facile / moins gênant d'appeler des procédures stockées, mais vous traitez toujours de jeux de données ou de lecteurs de données. Cela ne change pas réellement sur la manière dont vous interagissez avec la base de données, cela rend simplement moins gênant.
Cadre d'entité, d'autre part, concerne la modélisation des données et la cartographie relative à un objet. Cela fonctionne à un niveau supérieur à celui de la DAAB; Vous écrivez votre code en termes de vos objets et non en termes de jeux de données ou de digne de données. Il automatise la "matérialisation" des objets de la base de données de sorte que vous n'avez pas besoin d'écrire ce code, maintient les relations entre eux, etc. C'est un moyen de travailler beaucoup plus complet, mais très différent, de travailler avec la base de données. < / p>
Vous devez considérer si vous allez d'abord passer au style d'accès des données d'ormes. De là, vous pouvez décider si EF ou l'un des nombreux autres orateurs de l'espace .NET répondra mieux à vos besoins.
Il existe de nombreux fournisseurs disponibles pour EF (voir la réponse de Devart pour une liste) mais ils sont tous des coûts externes / supplémentaires. Le seul dans la boîte est pour SQL Server. Bien que j'ajouterai que DAAB ne couvre pas complètement la chose «Indépendance de la base de données» - si vous avez des SQL réels dans vos appels DAAB, cela ne vous aide pas avec des différences dans les dialectes SQL. Ef va.
Y a-t-il un avantage pour passer au cadre d'entité?
généralement plus rapide pour obtenir votre travail d'accès aux données effectué. La syntaxe LINQ est géniale et peut interroger SQL.
EF conservera notre critère de "moteur de base de données" non dépendant?
pas sans une autre 3ème partie soutien. Bien que je n'ai pas rencontré de développeurs qui prenaient en effet une demande de fonctionnement et des technologies de base de données commutées vers ou à partir de SQL.
ou devrions-nous conserver notre implémentation de DAAB ENTLIB, mais la mise à niveau de la Dernière version (5.0)?
daab est génial !! J'ai écrit un code générateur pour celui-ci .. Aussi après la mise en œuvre EF pour une grande base de données avec un très mauvais schéma relationnel J'ai trouvé que l'EF 'Wizard' a pris place à la main à la mise à jour, 3 min pour 110 tables SQL (environ). C'était trop lent et je suis retourné à Daab ... Je dirai que la voie à suivre est toutefois EF. J'essaye juste d'l'utiliser avec des procédures stockées et aucun suivi pour le meilleur performance . L'autre chose à prendre conscience de la FEE consiste à fusionner des conflits lorsque deux personnes mettent à jour les participations séparément. Cela peut être déroutant.
Si le bloc d'accès aux données de la bibliothèque d'entreprise fonctionne pour vous super, pourquoi la peine de changer. La plupart des exemples de cadre d'entité de la SP et de la communauté sont basés sur SQL Server, je ne sais pas à quel point les autres cadres sont robustes.