c# - from - querystring asp net

C#ASP.NET QueryString parser

Question

Si ha estado buscando una forma agradable y limpia de analizar los valores de su cadena de consulta, he encontrado esto:

 /// <summary>
/// Parses the query string and returns a valid value.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="key">The query string key.</param>
/// <param name="value">The value.</param>
protected internal T ParseQueryStringValue<T>(string key, string value)
{
if (!string.IsNullOrEmpty(value))
{
//TODO: Map other common QueryString parameters type ...
if (typeof(T) == typeof(string))
{
return (T)Convert.ChangeType(value, typeof(T));
}
if (typeof(T) == typeof(int))
{
int tempValue;
if (!int.TryParse(value, out tempValue))
{
throw new ApplicationException(string.Format("Invalid QueryString parameter {0}. The value " +
"''{1}'' is not a valid {2} type.", key, value, "int"));
}
return (T)Convert.ChangeType(tempValue, typeof(T));
}
if (typeof(T) == typeof(DateTime))
{
DateTime tempValue;
if (!DateTime.TryParse(value, out tempValue))
{
throw new ApplicationException(string.Format("Invalid QueryString parameter {0}. The value " +
"''{1}'' is not a valid {2} type.", key, value, "DateTime"));
}
return (T)Convert.ChangeType(tempValue, typeof(T));
}
}
return default(T);
}

Siempre quise tener algo así y finalmente lo hice bien ... al menos eso creo ...

El código debe ser auto explicativo ...

Cualquier comentario o sugerencia para mejorarlo es apreciado.

Answer 1

Dado que solo maneja tres tipos diferentes, sugeriría tres métodos diferentes en su lugar: los métodos genéricos son mejores cuando funcionan bien con cada argumento de tipo permitido por las restricciones de tipo.

Además, recomiendo encarecidamente que para int y DateTime se especifique la cultura que se utilizará, en realidad no debería depender de la cultura en la que se encuentre el servidor. (Si tiene un código para adivinar la cultura del usuario, podría utilícelo en su lugar.) Finalmente, también sugiero que se admita un conjunto de formatos DateTime bien especificado en lugar de simplemente lo que TryParse admita por defecto. ( ParseExact siempre uso ParseExact / TryParseExact lugar de Parse / TryParse ).

Tenga en cuenta que la versión de cadena realmente no necesita hacer nada, dado que el value ya es una cadena (aunque su código actual convierte "" a null , que puede ser o no lo que usted quiere).

Answer 2

En mi aplicación he estado usando la siguiente función:

public static class WebUtil
{
public static T GetValue<T>(string key, StateBag stateBag, T defaultValue)
{
object o = stateBag[key];
return o == null ? defaultValue : (T)o;
}
}

El valor predeterminado requerido se devuelve si el parámetro no se ha proporcionado, el tipo se deduce de defaultValue y las excepciones de conversión se generan según sea necesario.

El uso es el siguiente:

var foo = WebUtil.GetValue("foo", ViewState, default(int?));

Answer 3

Me parece que estás haciendo un montón de conversiones de tipo extravagante. Las variables tempValue están listas del tipo que está intentando devolver. Del mismo modo, en el caso de cadena, el valor ya es una cadena, así que solo devuélvalo.

Answer 4

Una forma simple de analizar (si no desea hacer conversiones de tipo) es

 HttpUtility.ParseQueryString(queryString);

Puede extraer la cadena de consulta de una URL con

 new Uri(url).Query

Answer 5

He escrito el siguiente método para analizar QueryString a valores fuertemente tipados:

public static bool TryGetValue<T>(string key, out T value, IFormatProvider provider)
{
string queryStringValue = HttpContext.Current.Request.QueryString[key];
if (queryStringValue != null)
{
// Value is found, try to change the type
try
{
value = (T)Convert.ChangeType(queryStringValue, typeof(T), provider);
return true;
}
catch
{
// Type could not be changed
}
}
// Value is not found, return default
value = default(T);
return false;
}

Ejemplo de uso:

int productId = 0;
bool success = TryGetValue<int>("ProductId", out productId, CultureInfo.CurrentCulture);

Para una cadena de consulta de ?productId=5 el bool sería verdadero y int productId sería igual a 5.

Para una cadena de consulta de ?productId=hello el bool sería falso e int productId equivaldría a 0.

Para una cadena de consulta de ?noProductId=notIncluded el bool sería falso e int productId equivaldría a 0.

Answer 6

Esta es una respuesta antigua, pero he hecho lo siguiente:

 string queryString = relayState.Split("?").ElementAt(1);
NameValueCollection nvc = HttpUtility.ParseQueryString(queryString);

Answer 7

Basado en la respuesta de Ronalds , he actualizado mi propio método de análisis de cadena de consulta. La forma en que lo uso es agregarlo como un método de extensión en el objeto de la página, así que es fácil para mí verificar los valores y tipos de la cadena de consulta y redirigir si la solicitud de la página no es válida.

El método de extensión se ve así:

public static class PageHelpers
{
public static void RequireOrPermanentRedirect<T>(this System.Web.UI.Page page, string QueryStringKey, string RedirectUrl)
{
string QueryStringValue = page.Request.QueryString[QueryStringKey];
if(String.IsNullOrEmpty(QueryStringValue))
{
page.Response.RedirectPermanent(RedirectUrl);
}
try
{
T value = (T)Convert.ChangeType(QueryStringValue, typeof(T));
}
catch
{
page.Response.RedirectPermanent(RedirectUrl);
}
}
}

Esto me permite hacer cosas como las siguientes:

protected void Page_Load(object sender, EventArgs e)
{
Page.RequireOrPermanentRedirect<int>("CategoryId", "/");
}

Luego puedo escribir el resto de mi código y confiar en la existencia y el formato correcto del elemento de la cadena de consulta, por lo que no tengo que probarlo cada vez que quiero acceder a él.

Nota: Si está utilizando pre .net 4, también querrá el siguiente método de extensión RedirectPermanent:

public static class HttpResponseHelpers
{
public static void RedirectPermanent(this System.Web.HttpResponse response, string uri)
{
response.StatusCode = 301;
response.StatusDescription = "Moved Permanently";
response.AddHeader("Location", uri);
response.End();
}
}