2009-11-18 14 views
12

A menudo termino rodando mis propios métodos de envoltura/extensión para/alrededor de System.Uri y me preguntaba si alguien sabe de una buena implementación de código abierto. Lo que más me gusta hacer es analizar los parámetros de la cadena de consulta, crear una nueva cadena de consulta (esta es la clave) y reemplazar los nombres de las páginas. ¿Tienes algunos buenos, o System.Uri es lo suficientemente bueno para ti?C# Url Builder Class

Respuesta

15

La clase de BradVin QueryString Builder es buena. Interfaz fluida y soporte para cifrado.

También vale la pena echarle un vistazo a esta clase de UrlBuilder en CodeProject. Similar a System.UriBuilder tiene mejor soporte para trabajar con QueryString.

+0

Felicitaciones por esta respuesta. Esto es casi textualmente con lo que he estado rodando durante años. No me gusta el UriBuilder porque quiero más funcionalidad para agregar dinámicamente parámetros qs. – Trent

6

Usamos nuestra propia clase de Uri alternativa que se basa parcialmente en Uri, como dices. Sin embargo, creo que hay una distinción importante que hacer: System.Uri generalmente está destinado a ser inmutable, o más precisamente, comportarse de manera inmutable. Una vez que se crea, representa un punto final de ubicación/recurso universal preciso. Si necesita describir una ubicación diferente, debe crear un Uri nuevo, no cambiar el existente.

Hay una clase separada que se especializa en producir Uri's: UriBuilder.

0

No estoy seguro exactamente de lo que está tratando de hacer (los ejemplos ayudarían) pero parece que está tratando de obtener algunas de las funcionalidades de mod_rewrite de Apache en ASP.NET.

Hay an article at MSDN exactamente sobre esto.

3

Entre System.Uri y System.UriBuilder, ¿qué características le falta exactamente a esas dos?

+0

Uri es inmutable como Rex M aclaró. Pero ni siquiera sabía sobre UriBuilder. Lo investigaré. – Trent

2
/// <summary> 
    /// The arguments must be like: varName1, varValue1, varName2, varValue2 and so on. 
    /// Empty names will be not be added to the result. 
    /// Returns a string of the form varName1=varValue1&varName2=varValue2... 
    /// </summary>  
    public static string BuildQueryString(params string[] strings) 
    { 
     Debug.Assert(0 == strings.GetLength(0) % 2); 

     StringBuilder builder = new StringBuilder(50); 
     bool isName = true; 
     bool isEmptyName = false; 

     foreach (string crtString in strings) 
     { 
      isEmptyName = (isName && string.IsNullOrEmpty(crtString)) || 
       (!isName && isEmptyName); 

      if (!isEmptyName) 
      { 
       builder.Append(HttpUtility.UrlEncode(crtString)); 

       if (isName) 
        builder.Append("="); 
       else 
        builder.Append("&"); 
      } 

      isName = !isName; 
     } 

     return builder.ToString(); 
    } 
12

Flurl [divulgación: Soy el autor] es un constructor de URL fluidez que tiene este aspecto:

var url = "http://www.some-api.com" 
    .AppendPathSegment("endpoint") 
    .SetQueryParams(new { 
     api_key = ConfigurationManager.AppSettings["SomeApiKey"], 
     max_results = 20, 
     q = "Don't worry, I'll get encoded!" 
    }); 

Si quieres pasar a ser la construcción de las direcciones URL con el propósito de llamándolos, Flurl.Http es una lib complementaria que le permite hacer HTTP fuera de la cadena fluida:

await "https://api.mysite.com" 
    .AppendPathSegment("person") 
    .SetQueryParams(new { ap_key = "my-key" }) 
    .WithOAuthBearerToken("MyToken") 
    .PostJsonAsync(new { first_name = firstName, last_name = lastName }); 

obtener el paquete completo en NuGet:

PM> Install-Package Flurl.Http

o simplemente el autónomo de creación de URL:

PM> Install-Package Flurl