La liaison des paramètres de la requête par un nom avec ODP.NET

Je suis actuellement à l'aide de Microsoft ADO.NET provider for Oracle (System.Data.OracleClient). Je suis conscient que ce n'est certainement pas le meilleur fournisseur Oracle disponible et qu'il sera bientôt obsolète, je devrais être à l'aide d'Oracle ODP.NET au lieu de cela. La raison pour laquelle j'utilise toujours le MME fournisseur est parce que ODP.NET elle lie les paramètres par position, non par leur nom. Cela peut vraiment être un pain PITA lorsque vous utilisez de nombreux paramètres dans une requête, parce que vous devez être prudent de les ajouter dans le bon ordre, ce qui peut facilement conduire à des bugs. C'est aussi ennuyeux quand vous utilisez le même paramètre plusieurs fois dans la même requête, par exemple :

SELECT A,B,C FROM FOO WHERE X = :PARAM_X OR :PARAM_X = 0

Avec ODP.NET je dois ajouter deux paramètres à la OracleCommand, je pense que c'est stupide...

ODP.NET's OracleCommand a la propriété de changer ce comportement par défaut : BindByName. Lorsque la valeur est true, les paramètres sont liés par un nom, qui est ce que je veux. Malheureusement, ce n'est pas vraiment m'aider, parce que :

  • Il est à false par défaut
  • Je n'ai presque jamais utiliser le béton ADO.NET les classes explicitement, je préfère utiliser ADO.NET 2.0 couche d'abstraction (DbProviderFactory, DbConnection, DbCommand...) afin de réduire le couplage à un SGBDR. Donc je n'ai pas accès à la BindByName propriété, à moins que je cast explicite OracleCommand, de perdre tous les avantages ou l'abstraction.
  • Lors de l'utilisation d'un ASP.NET SqlDataSource, je n'ai pas créer le DbCommand moi-même, donc je n'ai pas eu la chance de définir BindByName vrai (je pourrais le faire dans la Sélection de l'événement, mais c'est vraiment une douleur à faire pour chaque SqlDataSource...)

Comment suis-je censé s'occuper de ce problème ? Est-il un BindByNameByDefault réglage quelque part ? (Je n'ai pas trouver quelque chose comme ça, mais j'ai peut-être raté...)

Je viens de perdre 3 heures à cause de cette "fonctionnalité"!

OriginalL'auteur Thomas Levesque | 2009-06-25

  1. 7

    Je pense que vous pouvez créer votre propre fournisseur qui utilise les valeurs par défaut que vous souhaitez utiliser. Vous pourriez créer facilement de fournisseur en héritant de toutes les classes à partir de odp.net, il suffit de régler certaines propriétés comme BindByName.

    La DbProviderfactory permettra de créer vos classes au lieu de la normale odp.net des classes.

    Bonne idée, merci ! Je pense que je vais essayer ça
    OK, il semble possible, mais pas très simple... plus ODP.NET les classes sont scellés, donc je ne peux pas hériter de leur surcharger les méthodes, et en fonction de Réflecteur, il ya beaucoup d'endroits où OracleCommand constructeur est appelé explicitement... de toute façon, je ne peux pas penser à une meilleure solution, j'accepte votre réponse. Merci !

    OriginalL'auteur Theo

  2. 4

    D'utiliser l'indirection et de l'héritage! Si vous effectuez l'accès aux données par le biais d'un résumé de la Base de données de la classe, exiger la Base de données de mise en œuvre de la poignée de liaison de paramètre.

    public abstract class Database
{
    private readonly DbProviderFactory factory;

    protected Database(DbProviderFactory factory)
    {
        this.factory = factory;
    }

    public virtual DbCommand CreateCommand(String commandText)
    {
        return CreateCommand(CommandType.Text, commandText);
    }

    public virtual DbCommand CreateCommand(CommandType commandType, String commandText)
    {
        DbCommand command = factory.CreateCommand();
        command.CommandType = commandType;
        command.Text = commandText;
        return command;
    }

    public virtual void BindParametersByName(DbCommand command)
    {

    }
}

    Et choisissez de créer un Oracle de mise en œuvre spécifique qui remplace la commande par défaut de création ou offre la possibilité de lier des paramètres par nom.

    public class OracleDatabase : Database
{
    public OracleDatabase()
        : base(OracleClientFactory.Instance)
    {

    }

    public override DbCommand CreateCommand(CommandType commandType, String commandText)
    {
        DbCommand command = base.CreateCommand(commandType, commandText);
        BindParametersByName(command);
        return command;
    }

    public override void BindParametersByName(DbCommand command)
    {
        ((OracleCommand)command).BindByName = true;
    }
}

    De Code basé sur la Application D'Accès Aux Données Du Bloc dans le L'Entreprise De La Bibliothèque.

    Ceci est très similaire à ce que j'ai fait pour un projet. Le OracleDatabase classe fournit un bon point d'extension trop, pour l'ajout de méthodes pratiques que l'ODP.NET défaut de mise en œuvre ne fournit pas.
    Bien que cette solution est parfaite pour une utilisation dans le code C#, il n'aide pas dans le cas d'une ASP.NET SqlDataSource : je tiens à préciser une ADO.NET fournisseur, n'est pas coutume couche d'accès aux données...
    Levesque je suis familier avec le SqlDataSource, mais il semble que vous pourriez hériter de DataSourceControl et re-construire votre propre OracleDataSource... ça vous tente?

    OriginalL'auteur Anthony Mastrean

  3. 1

    Comme pour le retrait de la Microsoft ADO .NET fournisseur pour Oracle :

    • Je vais l'utiliser à la place de l'ODP .NET, votre problème n'en étant qu'un des nombreux problèmes avec elle. Et comme il va, il sera toujours disponible .NET 4.0, bien que non pris en charge.
    • Si Oracle parvient à rendre ce fournisseur inutilisable, je vais probablement aller avec une alternative commerciale comme DataDirect ADO.NET Fournisseur de Données Oracle ou dotConnect for Oracle, qui intègrent pleinement dans le ADO .NET framework. Et ils prennent déjà en charge le Cadre de l'Entité, par la voie (je crois que Oracle a déclaré ODP .NET ne serait pas).

    De l'ODP .NET pris trop de mon temps déjà.

    Vous avez probablement raison sur les fournisseurs tiers, mais ils ne sont pas gratuit, donc je ne suis pas sûr que je pourrais le convaincre mon employeur de les acheter... mais le Cadre de l'Entité en charge est un argument sérieux à mettre dans la balance. Je ne comprends pas pourquoi Oracle ne pas la mettre en œuvre dans ODP.NET...
    Je recommande fortement dotConnect for Oracle. Il vaut chaque dollar que vous payez pour cela.
    Oracle a commencé à soutenir Entity Framework en fait, il y a une beta ODP.net version avec EF et Linq soutien de la droite maintenant.
    En effet (oracle.com/technetwork/topics/dotnet/whatsnew/... et oracle.com/technetwork/topics/dotnet/downloads/...). Merci pour les commentaires. Combien d'Oracle spécifiques bizarreries ils parviennent à se glisser dans?

    OriginalL'auteur Mac