2010-08-03 12 views
8

Utilizamos el framework .NET 2.0 con C# 3.0 (creo que es la última versión de C# que se puede ejecutar en la versión 2.0 del framework, corrígeme si estoy equivocado).¿Una forma más sencilla de verificar los parámetros?

¿Hay algo incorporado en C# que pueda hacer que este tipo de validación de parámetros sea más conveniente?

public ConnectionSettings(string url, string username, string password, 
          bool checkPermissions) 
{ 
    if (username == null) { 
     throw new ArgumentNullException("username"); 
    } 

    if (password == null) { 
     throw new ArgumentNullException("password"); 
    } 

    if (String.IsNullOrEmpty(url)) { 
     throw new ArgumentException("Must not be null or empty, it was " + 
      (url == null ? url : "empty"), "url"); 
    } 

    this.url = url; 
    this.username = username; 
    this.password = password; 
    this.checkPermissions = checkPermissions; 
} 

Ese tipo de validación de parámetros se convierte en un patrón y los resultados común en una gran cantidad de código "casi repetitivo" para vadear a través de nuestros métodos públicos.

Si no hay nada incorporado. ¿Existen grandes librerías gratuitas que podamos usar?

+0

creo que esta necesidad línea de cambiar para evitar una excepción de referencia nula? (url == null? Url: "empty"), "url"); a (url == null? "Null": "empty"), "url"); – w69rdy

+0

Está buscando una herramienta de Programación Orientada a Aspectos. Sé que hay algunos por ahí, que se integran con Visual Studio e inyectan código en sus ensamblados IL en tiempo de compilación. Pero parece que no puedo hacer que mi google funcione esta mañana. – Will

+0

Debería poder utilizar algunos métodos de conveniencia para proporcionar la mayor parte de la funcionalidad, pero estoy de acuerdo, sería bueno tener algo de azúcar sintética para esto. Estoy especialmente cansado de lanzar dos excepciones separadas para los dos casos de cadena. IsNullOrEmpty – cristobalito

Respuesta

4

que suelen crear métodos de ayuda estáticas ...

P. ej

public static void CheckNotNull(object value, string parameterName) 
{ 
    if(value == null) { throw new ArgumentNullException(parameterName); } 
} 

significa que se puede condensar su código a algo similar a la de abajo y sólo lo hace un poco más ordenado.

CheckNotNull(username, "username"); 
CheckNotNull(password, "password"); 

O se puede envolver como un método de extensión:

public static void CheckNotNull<T>(this T value, string parameterName) 
{ 
    if(value == null) { throw new ArgumentNullException(parameterName); } 
} 

Y utilizar como:

username.CheckNotNull("username"); 
password.CheckNotNull("password"); 

Y si se siente realmente de lujo, que probablemente se podría interrogar al nombres de parámetros mediante el uso de la reflexión. La reflexión es un poco lenta, por lo que solo harías esto si hicieras una excepción, pero te ahorra escribir el nombre del parámetro literal todo el tiempo.

+0

Todavía requiere poner el nombre del parámetro en una cadena (que de manera conveniente ha omitido). –

+0

Ben, de hecho, eso fue un error, pero se corrigió antes del voto a favor. – Ian

+0

Y deshice el voto negativo ahora que veo que lo has arreglado. –

2

Puede hacerlo mediante contratos pero es el mismo concepto.

Esto debería ser una buena práctica de todos modos, ya que muestra claramente cuáles son los campos obligatorios en un método público.

3

Here's a nice fluent way de hacer esto.

What are your favorite extension methods for C#? (codeplex.com/extensionoverflow)

public static class Extensions 
{ 
     public static void ThrowIfArgumentIsNull<T>(this T obj, string parameterName) where T : class 
     { 
       if (obj == null) throw new ArgumentNullException(parameterName + " not allowed to be null"); 
     } 
} 

internal class Test 
{ 
     public Test(string input1) 
     { 
       input1.ThrowIfArgumentIsNull("input1"); 
     } 
} 
+0

Giorgi ya mencionó este método. Además ... todavía tienes esa cadena fea con el nombre del parámetro en ella. –

2

Idea similar a la validación de parámetros fluida mencionada por Giorgi, pero esta evita el nombramiento redundante del parámetro y las cadenas que no se pueden actualizar automáticamente mediante herramientas de refactorización de código.

http://charlieflowers.wordpress.com/tag/parameter-validation/

4

Se podría utilizar un tejedor il como Post Sharp, tener en cuenta que el compilador como un servicio en C# 5 hará que este tipo de cosas incorporada.

Personalmente no recomendaría este enfoque a menos el problema es enorme y debe abordarse. Por lo general, algunas aseveraciones y verificaciones previas como describió anteriormente son una mejor práctica.

Ejem:

public ConnectionSettings(
    [NotNullOrEmpty] string url, 
    [NotNull] string username, 
    [NotNull] string password, 
    bool checkPermissions) 
{ 
    this.url = url; 
    this.username = username; 
    this.password = password; 
    this.checkPermissions = checkPermissions; 
} 

También podría integrar este tipo de cosas con code contracts lo que permitiría llevar a cabo algunos ricos análisis estático.

Cuestiones relacionadas