with net method español create c# .net reflection

net - reflection c# español



Justificación para la reflexión en C# (6)

Reflection hace que sea muy fácil implementar arquitecturas de plugins donde los plugins DLL se cargan automáticamente en tiempo de ejecución (no vinculados explícitamente en tiempo de compilación).

Se pueden escanear para las clases que implementan / extienden interfaces / clases relevantes. La reflexión se puede usar para crear instancias de estos a pedido.

Me he preguntado acerca de lo apropiado de la reflexión en el código C #. Por ejemplo, he escrito una función que itera a través de las propiedades de un objeto fuente dado y crea una nueva instancia de un tipo especificado, luego copia los valores de las propiedades con el mismo nombre de una a la otra. Creé esto para copiar datos de un objeto LINQ autogenerado a otro con el fin de evitar la falta de herencia de múltiples tablas en LINQ.

Sin embargo, no puedo evitar pensar que un código como este es realmente ''trampa'', es decir, en lugar de usar los constructos de lenguaje proporcionados para lograr un fin dado, te permite eludirlos.

¿Hasta qué punto es aceptable este tipo de código? ¿Cuáles son los riesgos? ¿Cuáles son los usos legítimos de este enfoque?


A veces, usar la reflexión puede ser un poco complicado, pero muchas veces es simplemente la herramienta de código más fantástica.

Observe la cuadrícula de propiedades de .Net, cualquiera que haya usado Visual Studio lo conocerá. Puede apuntar a cualquier objeto y generará un editor de propiedades simple. Eso usa la reflexión, de hecho, la mayoría de las herramientas de VS sí lo hacen.

Mire las pruebas unitarias: están cargadas por reflexión (al menos en NUnit y MSTest).

Reflection permite un comportamiento de estilo dinámico a partir de lenguajes estáticos.

Lo único que realmente necesita es escribir patos: el compilador de C # ya lo admite: puede foreach cualquier cosa que se parezca a IEnumerable , ya sea que implemente o no la interfaz. Puede usar la sintaxis de la colección C # 3 en cualquier clase que tenga un método llamado Add .

Use la reflexión donde sea que necesite un comportamiento de estilo dinámico; por ejemplo, tiene una colección de objetos y desea verificar la misma propiedad en cada uno.

Los riesgos son similares para los tipos dinámicos: las excepciones de tiempo de compilación se vuelven de tiempo de ejecución. Tu código no es tan ''seguro'' y tienes que reaccionar en consecuencia.

El código de reflexión .Net es muy rápido, pero no tan rápido como habría sido la llamada explícita.


Estoy de acuerdo, me da la sensación de que funciona, pero se siente como un hackeo . Intento evitar la reflexión siempre que sea posible. Me han quemado muchas veces después de refactorizar el código que tenía reflejo en él. El código compila bien, las pruebas incluso se ejecutan, pero en circunstancias especiales (que las pruebas no cubrieron) el programa explota en tiempo de ejecución debido a mi refactorización en uno de los objetos en los que se introdujo el código de reflexión.

Ejemplo 1: Reflexión en OR mapper, cambia el nombre o el tipo de la propiedad en su modelo de objeto: aumenta el tiempo de ejecución.

Ejemplo 2: estás en una tienda SOA. Los servicios web están completamente desacoplados (o eso crees). Tienen su propio conjunto de clases proxy generadas, pero en el mapeo decides ahorrar algo de tiempo y haces esto:

ExternalColor c = (ExternalColor)Enum.Parse(typeof(ExternalColor), internalColor.ToString());

Bajo las sábanas, esto también es reflejo, pero lo hace el propio framework .net. Ahora, ¿qué sucede si decide cambiar el nombre de InternalColor.Grey a InternalColor.Gray ? Todo parece estar bien, se construye bien, e incluso funciona bien ... hasta el día en que un usuario estúpido decida usar el color Gris ... en ese punto el mapeador explotará.


Puede que sea solo yo, pero la forma en que me gustaría entrar en esto es creando un generador de código: usar la reflexión en el tiempo de ejecución es un poco costoso y sin tipo. Crear clases que se generarían de acuerdo con su último código y copiar todo de una manera fuertemente tipada significaría que detectará estos errores en tiempo de compilación.

Por ejemplo, una clase generada puede verse así:

static class AtoBCopier { public static B Copy(A item) { return new B() { Prop1 = item.Prop1, Prop2 = item.Prop2 }; } }

Si cualquiera de las clases no tiene las propiedades o sus tipos cambian, el código no se compila. Además, hay una gran mejora en los tiempos.


Recientemente utilicé la reflexión en C # para encontrar implementaciones de una interfaz específica. Había escrito un intérprete simple de estilo por lotes que buscaba "acciones" para cada paso del cálculo en función del nombre de la clase. Reflejando el espacio de nombres actual, aparece la implementación correcta de mi interfaz IStep que puede ejecutarse (). De esta forma, agregar nuevas "acciones" es tan fácil como crear una nueva clase derivada, sin necesidad de agregarlo a un registro, o incluso peor: olvidar agregarlo a un registro ...


La reflexión es una herramienta maravillosa que no podría vivir sin ella. Puede hacer la programación mucho más fácil y más rápida.

Por ejemplo, uso la reflexión en mi capa ORM para poder asignar propiedades con valores de columna de tablas. Si no fuera por la reflexión, he tenido que crear una clase de copia para cada mapeo de tabla / clase.

En cuanto a la excepción de color externo anterior. El problema no es Enum.Parse, sino que el codificador no detectó la excepción adecuada. Como se analiza una cadena, el codificador siempre debe suponer que la cadena puede contener un valor incorrecto.

El mismo problema se aplica a toda la programación avanzada en .Net. "Con un gran poder viene una gran responsabilidad". Usar la reflexión te da mucho poder. Pero asegúrese de saber cómo usarlo correctamente. Hay docenas de ejemplos en la web.