Este tema me lo ha recordado hoy por la mañana un alumno de mi curso de "Técnicas de escritura de código seguro" de campusMVP. Me parece muy interesante comentarlo aquí y de paso contestarle a él el porqué de que ocurra... (Gracias por recordármelo, Iván).

Resulta que en ADO.NET 1.x (ya "clásico"), estamos acostumbrados a hacer algo similar a lo siguiente:

SqlCommand cmd = new SqlCommand("SELECT * FROM Tabla WHERE campo = @Parametro");
cmd.Parameters.Add("@Parametro", 1);

suponiendo que, por ejemplo, el parámetro "@Parametro" es un valor numérico.

Hasta aquí todo normal. El caso es que si en un programa escrito con ADO.NET 2.0 escribimos exactamente lo  mismo, aunque funcionará por compatibilidad, el compilador y el propio entorno de Visual Studio nos darán un aviso diciendo que el método 'Add' está obsoleto (deprecated en inglés) y que es mejor que usemos el método AddWithValue. ¿Por qué este cambio tan aparentemente arbitrario?

De hecho en Microsoft dicen que en versiones posteriores de.NET (la 3 o la que sea la siguiente) es posible que el método Add no esté soportado en absoluto :-(((

El motivo es el siguiente: cuando el parámetro es de otro tipo no numérico (una cadena o una fecha) no hay problemas. Pero si el parámetro es numérico como en el ejemplo anterior: ¿qué creeis que pasará cuando llamemos al código de ejemplo?

De entrada cabría pensar lo obvio: que se asigna el parámetro "@Parametro" con el valor '1'. Sin embargo no es así. Lo que ocurre en realidad es que el compilador mira cuál de los métodos Add sobrecargados se ajusta mejor y resulta que el que mejor lo hace es, precisamente el siguiente:

public SqlParameter Add(string parameterName, SqlDbType sqlDbType)

es decir, el segundo parámetro en lugar de interpretarse como un valor para ser asignado se interpreta como un valor de tipo SqlDbType que se ajusta mucho mejor (en concreto en nuestro ejemplo como SqlDbType.Binary que se corresponde con el 1). Es decir, en lugar de asignar el parámetro estamos indicando que el parámetro es de tipo binario, que no es precisamente lo que queríamos. Por supuesto la aplicación romperá. Un verdadero peligro.

De ahí que los chicos de Microsoft hayan tomado la dolorosa decisión de cambiar el método de asignación e, incluso, se planteen eliminar el anterior de la API. Razón no les falta pero es un poco fastidioso.

Así que ya sabes: vete acostumbrándote a usar AddWithValue.

NOTA: Esta es la definición del método Add sacada directamente del código fuente de System.Data.SqlClient en .NET 2.0:

[Obsolete("Add(String parameterName, Object value) has been deprecated.  Use AddWithValue(String parameterName, Object value).  http://go.microsoft.com/fwlink/?linkid=14202", false), EditorBrowsable(EditorBrowsableState.Never)]
public SqlParameter Add(string parameterName, object value);

Fíjate que el enlace del comentario nos lleva a la lista de APIs obsoletas en .NET 2.0. Vale la pena echarle un vistazo.

💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor

Escrito por un humano, no por una IA