2011-01-28 1 views
7

Dans le bon vieux temps OleDb j'ai utilisé UDL fichiers et l'assistant associés pour vérifier et créer des chaînes de connexion. De nos jours, les chaînes de connexion que vous pouvez créer de cette manière ne sont plus universelles. Le ADO.NET Entity Framework par exemple crée des chaînes de connexion de l'assistant qui Décorés UDL ne peut pas gérer. Existe-t-il un outil pour créer les liens de données universels d'aujourd'hui?Où sont les liens de données vraiment universels?

+2

Comment très intéressant. C'est comme si c'était juste devenu pouf. Impossible de trouver quoi que ce soit disant qu'il était obsolète ou obsolète. – Amy

Répondre

3

Je pense qu'il ya une différence entre:

  • L'outil qui permet de créer des chaînes de connexion (celle qui apparaît lorsque vous double cliquez sur le fichier .UDL). Cet outil est basé sur COM et réside dans Ole32.dll et fonctionne toujours.
  • Le concept de chaînes de connexion qui n'a jamais changé. (C'est si simple: une liste de paire clé/valeur!)

Les chaînes de connexion d'aujourd'hui (par exemple: .NET?) ne sont pas moins universelles que les chaînes de connexion OleDb. Ils sont toujours spécifiques à un fournisseur donné. Les paires clé/valeur peuvent ne pas être les mêmes, mais le concept est toujours là.

L'outil UDL fonctionne à l'aide d'objets COM et peut encore être utilisé. Par exemple, on pourrait écrire une extension à l'outil UDL pour les chaînes de connexion Entity Framework. Voici un lien sur la référence officielle: Provider Extensible Data Link User Interface API

fichiers .UDL sont utilisables dans .NET (avec P/Invoke) en utilisant IDBPromptInitialize et les interfaces de IDataInitialize OleDb, même si je suis d'accord, il ne semble pas si naturel ces jours :)

3

Un « lien de données » universel ne peut pas soutenir toutes fonctions de tous les vendeurs/versions de bases de données, logiciel plus est écrit dans la maison par les entreprises pour parler à leurs bases de données maison, donc ne doivent pas nécessairement être indépendant de la base de données.

Il est plus difficile à coder contre une API qui n'est pas un bon match pour les fonctions de votre base de données choisie fournit que la documentation ne semble jamais correspondre à la base de données que vous essayez d'utiliser. Microsoft s'attend maintenant à ce que le fournisseur de base de données fournisse le support d'accès aux données Ado.net pour la base de données, donc l'accès aux données a tendance à être différent pour chaque base de données - mais la plupart des gens s'en foutent. avec un seul fournisseur de base de données.

Il existe des options tierces comme, devArt's dotConnect et DataDirect qui fournit un "lien de données" universel pour .net mais à un prix.

nHibernate sera placé au-dessus de la plupart des fournisseurs de la couche d'accès à la base de données .net et cacher la plupart des différences si vous êtes heureux d'utiliser un ORM.

Questions connexes