sirve - instanciar una clase c#
C#utilizando la directiva de espacios de nombres en espacios de nombres anidados (5)
Cuando se encuentra en un ámbito que no necesita System.Data , es mejor si el IntelliSense no desencadena los miembros de System.Data solo para meterse con otras cosas que está buscando.
Acerca de algún problema de rendimiento: no creo que importe cómo prefiera usarlo ...
Correcto, generalmente he usado las directivas ''using'' de la siguiente manera
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace AwesomeLib
{
//awesome award winning class declarations making use of Linq
}
Recientemente he visto ejemplos de tales como
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace AwesomeLib
{
//awesome award winning class declarations making use of Linq
namespace DataLibrary
{
using System.Data;
//Data access layers and whatnot
}
}
De acuerdo, entiendo que puedo poner USING dentro de mi declaración de espacio de nombres. Tal cosa tiene sentido para mí si tus espacios de nombres están en la misma raíz (se organizaron).
System;
namespace 1 {}
namespace 2
{
System.data;
}
Pero, ¿qué pasa con los espacios de nombres anidados? Personalmente, dejaría todas las declaraciones de USO en la parte superior donde puede encontrarlas fácilmente. En cambio, parece que se extienden por todo el archivo fuente.
¿Hay algún beneficio para las directivas de USO que se utilizan de esta manera en los espacios de nombres anidados? ¿Como la gestión de memoria o el compilador JIT?
De las reglas de Style Cop :
- Colocar directivas de uso de alias dentro del espacio de nombres elimina la confusión del compilador entre los tipos en conflicto.
- Cuando se definen múltiples espacios de nombres dentro de un único archivo, colocando directivas dentro de los elementos del espacio de nombres, referencias de ámbitos y alias.
Las cláusulas de uso solo ayudan a que su código sea más fácil de mantener, no afectan el rendimiento de su código AFAIK.
Lo mismo se aplica a los espacios de nombres: puede poner todas sus clases en el espacio de nombres global y nombrarlas como Clase1, Clase2, etc., y su código funcionará igual de bien. ¡Pero sería una pesadilla mantener!
Entonces ambos están ahí para ayudarlo, el codificador, no afectan el código compilado.
No hay beneficio para el lenguaje intermedio generado. Como el CIL es la entrada para el compilador JIT, esto tampoco se ve afectado.
Ya que está hablando de las mejores prácticas: lo mejor es tener solo una clase por archivo, por lo que también tendría un solo espacio de nombres.
El código IL no refleja C # using
Runtime Performance
¿Hay algún beneficio para las directivas de USO que se utilizan de esta manera en los espacios de nombres anidados? ¿Como la gestión de memoria o el compilador JIT?
Debido a que está preguntando sobre el rendimiento del tiempo de ejecución, aquí le damos un vistazo de lo que sucede debajo del código fuente.
Si miras el código IL compilado con la herramienta IL Diassembler de Microsoft (como lo estamos haciendo aquí) verás que todos los nombres de clase están totalmente calificados todo el tiempo, sin importar cómo el programador los usó en el código fuente.
En la siguiente muestra del código IL compilado, no se ve ningún mecanismo de "acceso directo" aunque el using encontraba en los archivos de código fuente originales de C #. Por ejemplo, IL describe una extensión larga extends [System.Web]System.Web.UI.Page mientras que C # debería haber utilizado : Page y también el using System.Web.UI; (dos declaraciones separadas).
// ***** Compiled MSIL CODE ****
// Notice all fully qualified classes throughout.
//
.class public auto ansi beforefieldinit WebApplication1.process
extends [System.Web]System.Web.UI.Page
{
.field family class [System.Web]System.Web.UI.HtmlControls.HtmlForm form1
.method family hidebysig instance void
Page_Load(object sender,
class [mscorlib]System.EventArgs e) cil managed
{
// Code size 95 (0x5f)
.maxstack 4
.locals init ([0] string strName,
[1] string strTime)
IL_0000: nop
IL_0001: ldarg.0
IL_0002: call instance class [System.Web]System.Web.HttpRequest [System.Web]System.Web.UI.Page::get_Request()
IL_0007: ldstr "name"
IL_000c: callvirt instance string [System.Web]System.Web.HttpRequest::get_Item(string)
En el IL compilado, todas las clases están completamente calificadas independientemente.
Esto significa que no hay beneficios o inconvenientes de rendimiento en el tiempo de ejecución en función del tiempo de diseño que using declaraciones.
Tiempo de compilación
Dependiendo de cómo disemine sobre su using y el namespace en el código fuente, puede haber más o menos palabras clave. El compilador tiene que verlos a todos y procesarlos todos, pero en general el rendimiento de la compilación sería insignificante por algo tan trivial, en comparación con todas las cosas que un compilador tiene que hacer para fabricar el producto final.
Beneficios de tiempo de diseño
los espacios de nombres son una técnica organizativa y su using es una forma de administrarlos en el nivel del código fuente (y de instruir al compilador sobre cómo los está usando para que pueda compilar el programa en consecuencia). Cuando la fuente de C # especifica el using System.Web.UI; , no se importa nada y el tamaño del archivo no crece (porque el ensamblado ya está referenciado); en su lugar, using simplemente está efectuando una sintaxis más corta para el contenido de ese espacio de nombres , dentro del alcance en el que se usa, ya sea en todo el alcance del archivo o en un ámbito de espacio de nombres declarado dentro del archivo.
El beneficio para el programador es la reducción de los conflictos de nombres de clase ambiguos entre espacios de nombres múltiples using s si se usan juiciosamente.
La organización de los espacios de nombres del código fuente se representa de manera diferente en el código IL compilado (como se ve en el ejemplo anterior).