是否存在适配不支持命名SQL参数的.NET数据提供程序的装饰器？

核心原因 #

ODBC规范原生仅支持位置参数（占位符为?），不内置命名参数映射能力，所以System.Data.Odbc的实现默认不会处理@/:开头的命名参数，这是底层设计限制，和SQL方言的参数前缀无关。

可行解决方案 #

你不需要完全修改上层的抽象逻辑，只要加一层轻量转换封装即可，不需要依赖第三方额外组件：

1. 自行实现命名参数转位置参数逻辑 #

在你抽象的数据库访问层和ODBC提供程序之间加一层转换即可，实现逻辑如下：

• 解析传入的带命名参数的SQL语句，按出现顺序提取所有命名参数（注意跳过单引号/双引号包裹的字符串常量中的同类字符，避免把邮箱、特殊标识误识别为参数）
• 把SQL中的所有命名参数占位符依次替换为?
• 按照提取到的参数顺序，重新排序你传入的DbParameter集合，保证参数顺序和占位符出现顺序完全一致
• 将转换后的SQL和重排后的参数绑定到OdbcCommand执行即可

示例转换效果：
原始SQL：

SELECT alpha, beta
FROM gamma
WHERE delta = @epsilon AND create_time > @startTime

转换后SQL：

SELECT alpha, beta
FROM gamma
WHERE delta = ? AND create_time > ?

参数集合按@epsilon、@startTime的顺序排序后传入，执行效果和使用命名参数完全一致，上层业务代码不需要做任何修改。

2. 基于DbCommand实现通用装饰器 #

如果你希望对上层完全屏蔽底层差异，可以自己实现一个DbCommand的装饰器类：

• 内部持有真实的DbCommand实例（可能是ODBC的OdbcCommand，也可能是原生提供程序的命令对象）
• 重写CommandText属性的赋值逻辑，自动判断底层是否为ODBC提供程序，如果是则自动完成命名参数解析和占位符替换
• 重写ExecuteNonQuery/ExecuteReader等执行方法，在执行前自动按解析出的参数顺序调整参数集合的排序
• 上层代码始终面向DbCommand抽象编程，完全不需要感知底层的参数处理逻辑

内容的提问来源于stack exchange，提问作者pvoosten