¿Cómo detectar si el elemento existe utilizando una expresión lambda en C#?

Question

He estado usando una instrucción try/catch para ejecutar si un elemento existe o no cuando lo analizo. Obviamente, esta no es la mejor manera de hacerlo. He estado utilizando LINQ (expresiones lambda) durante la mayoría de mi análisis sintáctico, pero no sé cómo detectar si un elemento está allí o no.

Un gran problema con algunas soluciones que encontré es que toman 3-4 veces más código que utilizando el bloque try/catch, lo que da un traspié al propósito.

yo asumiría el código sería algo como esto:

if(document.Element("myElement").Exists()) 
{ 
    var myValue = document.Element("myElement").Value; 
} 

he encontrado este link, pero el bucle es innecesario en mi caso como puedo garantizar que sólo se mostrará una vez si es que existe . Además del hecho de tener que crear un elemento ficticio que parece innecesario también. No parece que sea la mejor manera (o una buena forma) de verificar. ¿Algunas ideas?

Answer 1

XElement e = document.Element("myElement"); 
if (e != null) 
{ 
    var myValue = e.Value; 
} 

http://msdn.microsoft.com/en-us/library/system.xml.linq.xcontainer.element.aspx

"recibe la primera (en orden documento) elemento secundario con el XName especificado."

"Devuelve nada si no hay ningún elemento con el nombre especificado."

Answer 2

Cualquiera() es el comando Linq.

Assert.IsFalse(new [] { 1, 2, 3, 4 }.Any(i => i == 5)); 

Answer 3

Any() es la forma más sencilla de comprobar si existe un elemento.

Si tiene que asegurarse de que el elemento sea único, tendrá que hacer algo como .Count() == 1. Alternativamente, podría implementar su propio método de extensión, pero esto sería solo un contenedor alrededor del .Count == 1.

Answer 4

Por cierto, el comentario anterior sobre "try/catch" puede ser cierto, pero no es en casi todos los casos. Depende de cómo construyas tu solución. En su compilación Release, apague tantas banderas como sea posible que huelan a "Debug" incluso desde la distancia. Cuanto menos se le haya ordenado al tiempo de ejecución que memorice los restos de la pila y otras cosas durante la construcción, se volverá más rápido "try/catch".

Btw, # 2: Los famosos patrones arquitectónicos "¡Díselo, no preguntes!" (TDA) y el "Principio de cierre abierto" (OCP) prohíben el uso de un código tan infame como "if (! (Fp = fopen (...))". No solo lo alientan a utilizar "try"/catch "pero obligarlo a hacerlo. Porque el OCP no solo exige obedecer dentro de su propio código sino también cuando llama cosas extranjeras (es decir, bibliotecas como stdio).

¿Por qué OCP, no TDA en la última oración? no se te permite ampliar el significado del código existente. Siguiendo con el ejemplo simple "fopen", ¿qué vas a hacer cuando el resultado sea cero? ¿Por qué falló exactamente "fopen"? Podrías comprobar si hay suficiente espacio vacío a la izquierda, o si el sistema de archivos es grabable. De si el nombre del archivo es válido, o lo que sea. Sin embargo, su objetivo no puede lograrse: abra el archivo. Imagine una aplicación sin cabeza, por lo que no es posible la intervención del usuario. ¿Y ahora qué? Ahí no hay razón para buscar algo más a escondidas, porque falló "fopen". Necesitarás una estrategia de respaldo. Punto. Si "fopen" ha fallado, ha fallado.

Regla general: piense que su código siempre tiene éxito (KIS).Si su código voluntariamente puede "fallar" en términos de que un conjunto de resultados regularmente puede contener elementos o no, ponga la lógica en la clase. Quizás tenga que distribuir datos, propiedades, preguntas y métodos en diferentes clases (TDA). Quizás deba reajustar su código de acuerdo con SLA.

En su caso, asegúrese de que el elemento exista. Si no puedes, no es tu culpa. En el fondo de su código (un contenedor en el que se embellecen todos los errores de los antiguos codificadores), transforme los datos necesarios en otra entidad de manera que más allá no haya necesidad de "si".