Liaison des paramètres de requête par nom avec ODP.NET

Question

J'utilise actuellement le fournisseur Microsoft ADO.NET pour Oracle (System.Data.OracleClient). Je suis conscient que ce n'est certainement pas le meilleur fournisseur Oracle disponible et qu'il le soit sera bientôt obsolète , je devrais plutôt utiliser ODP.NET d'Oracle. La raison pour laquelle j'utilise toujours le fournisseur MS est parce que ODP.NET lie les paramètres par position , et non par leur nom. Cela peut vraiment être un PITA lorsque vous utilisez plusieurs paramètres dans une requête, car vous devez être prudent pour les ajouter dans le bon ordre, ce qui peut facilement conduire à des bogues. C'est également gênant lorsque vous utilisez plusieurs fois le même paramètre 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 au OracleCommand, ce qui, à mon avis, est stupide ...

ODP.NET BindByName a une propriété pour modifier ce comportement par défaut: DbProviderFactory. Lorsqu'il est défini sur true, les paramètres sont liés par un nom, ce que je veux. Malheureusement, cela ne m'aide pas vraiment, car:

• Il est défini sur false par défaut
• Je n'utilise presque jamais explicitement les classes ADO.NET concrètes. Je préfère utiliser la couche d'abstraction ADO.NET 2.0 (DbConnection, DbCommand, BindByNameByDefault ...) pour réduire le couplage à un SGBDR spécifique. Je n'ai donc pas accès à la propriété <=>, à moins que je spécifie explicitement <<>, ce qui entraîne la perte de tous les avantages ou de l'abstraction.
• Lorsque j'utilise un SqlDataSource ASP.NET, je ne crée pas le DbCommand moi-même, je n'ai donc pas la possibilité de définir <=> sur true (je pourrais le faire dans l'événement Selecting, mais c'est vraiment une peine de le faire pour chaque SqlDataSource ...)

Comment suis-je censé gérer ce problème? Existe-t-il un paramètre <=> quelque part? (Je n'ai rien trouvé de tel, mais ça m'a peut-être manqué ...)

Answer 1

Je pense que vous pouvez créer votre propre fournisseur en utilisant les paramètres par défaut que vous souhaitez utiliser. Vous pouvez facilement créer ce fournisseur en héritant de toutes les classes de odp.net. Il vous suffit de régler certaines propriétés telles que BindByName.

DbProviderfactory créera vos classes à la place des classes normales odp.net.

Answer 2

Utilisez l'indirection et l'héritage! Si vous accédez aux données via une classe de base de données abstraite, exigez la liaison du paramètre de descripteur d'implémentation de la base de données.

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 une implémentation spécifique à Oracle qui remplace la création de commande par défaut ou offre la possibilité de lier les paramètres par leur 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;
    }
}

Code basé sur le Bloc d'application Accès aux données . dans la bibliothèque Enterprise .

Answer 3

En ce qui concerne l'arrêt du fournisseur Microsoft ADO .NET pour Oracle:

• Je continuerai à l’utiliser au lieu d’ODP .NET, votre problème n’est qu’un des nombreux problèmes qu’il pose. Et comme cela va, il sera toujours disponible dans .NET 4.0, bien que non pris en charge.
• Si Oracle parvient à rendre ce fournisseur inutilisable, je choisirai probablement une alternative commerciale telle que DataDirect Fournisseur de données ADO.NET pour Oracle ou dotConnect pour Oracle , qui s'intègrent totalement dans le framework ADO .NET. Et ils prennent déjà en charge Entity Framework, à propos (je pense que Oracle a déclaré que ODP .NET ne le ferait pas).

ODP .NET a déjà pris trop de temps.