Pregunta

Mi experiencia es principalmente como desarrollador de Java, pero últimamente he estado trabajando en .NET.Así que he estado intentando hacer algunos proyectos simples en casa para mejorar mi trabajo con .NET.He podido transferir gran parte de mi experiencia en Java al trabajo con .NET (específicamente C#), pero lo único que realmente me ha dejado perplejo son los espacios de nombres.

Sé que los espacios de nombres son similares a los paquetes de Java, pero por lo que puedo decir, la principal diferencia es que con los paquetes de Java usan carpetas de archivos reales para mostrar la separación, mientras que en .NET no es así y todos los archivos residen en una sola carpeta. y el espacio de nombres simplemente se declara en cada clase.

Esto me parece extraño, porque siempre vi los paquetes como una forma de organizar y agrupar código relacionado, haciéndolo más fácil de navegar y comprender.Dado que en .NET no funciona de esta manera, con el tiempo, el proyecto parece más saturado y no es tan fácil de navegar.

¿Me estoy perdiendo de algo?Tengo que ser.¿Debería dividir las cosas en proyectos separados dentro de la solución?¿O existe una mejor manera de mantener las clases y archivos organizados dentro de un proyecto?

Editar:Como señaló Blair, ésta es más o menos la misma pregunta formulada aquí.

¿Fue útil?

Solución

No puedo afirmar que sea una buena práctica, pero a menudo veo archivos organizados en una jerarquía de directorios que refleja el espacio de nombres.Si se ajusta mejor a su modelo mental del código, hágalo; no se me ocurre ningún daño.El hecho de que el modelo .NET no imponga relaciones entre espacios de nombres, proyectos y estructura de directorios no significa que no pueda tener dichas relaciones si así lo desea.

Sería un poco reticente a dividir el código en más proyectos de los necesarios, ya que esto puede ralentizar la compilación y agregar un poco de sobrecarga cuando tienes que administrar múltiples ensamblados.

EDITAR:Tenga en cuenta que esta pregunta es casi un duplicado de ¿Las carpetas de una solución deberían coincidir con el espacio de nombres?

Otros consejos

Sí, en el espacio de nombres .NET no depende del sistema de archivos ni de nada más.Es una gran ventaja en mi opinión.Por ejemplo, puede dividir su código en diferentes ensamblados, lo que permite una distribución flexible.

Cuando se trabaja en Visual Studio, el IDE tiende a introducir un nuevo espacio de nombres cuando agrega una nueva carpeta al árbol del proyecto.

Aquí hay un enlace útil de MSDN:

Directrices para la nomenclatura de espacios de nombres

La regla general para nombrar espacios de nombres es usar el nombre de la compañía seguido del nombre de la tecnología y opcionalmente la función y el diseño de la siguiente manera.
Nombre de la empresa.Nombre de la tecnología[.Característica][.Diseño]

Por supuesto, puede utilizar espacios de nombres de la forma que considere más adecuada.Sin embargo, si va a compartir su código, le recomendaría seguir los estándares aceptados.

EDITAR:

Recomiendo encarecidamente a cualquier desarrollador .net que obtenga una copia de Directrices de diseño del marco. Este libro le ayudará a comprender cómo y por qué .NET está diseñado.

Una solución VS normalmente contiene uno o más proyectos.Estos proyectos tienen espacios de nombres predeterminados (normalmente el espacio de nombres es sólo el nombre del proyecto).Normalmente, si agrega una carpeta dentro del proyecto, todas las clases que contenga se nombrarán de la siguiente manera:

Espacio de nombres predeterminado.Nombre de carpeta.Nombre de clase

Por supuesto, puedes cambiar el espacio de nombres predeterminado del proyecto y hacer que tus clases reciban el nombre que desees.

En cuanto a cuándo y cómo dividir cosas en proyectos, es una cuestión de experiencia y/o preferencia.Sin embargo, es absolutamente necesario dividir las cosas en proyectos dentro de una solución para mantener su proyecto organizado.Si gestionar demasiados ensamblajes se vuelve engorroso (como sugirió Blair), siempre puedes ILFusionar sus ensamblajes en un solo ensamblaje.Lo bueno de ILMerge es que aunque termines con un solo ensamblado, todas tus clases conservan sus nombres completos originales.

También es importante recordar que una solución VS no influye en el código, es decir.no se construyen.Las Soluciones VS no son más que una forma de agrupar proyectos;son los proyectos los que se construyen y se convierten en archivos DLL.

Finalmente, VS le permite agregar carpetas "virtuales" en cualquier parte de la solución.Estas carpetas no se asignan a una carpeta en el sistema de archivos y simplemente se utilizan como otro medio para ayudarlo a organizar sus proyectos y otros artefactos dentro de la solución.

Los espacios de nombres son una agrupación lógica, mientras que los proyectos son una agrupación física.

¿Porque es esto importante?Piense en .NET 2.0, 3.0 y 3.5..NET 3.0 es básicamente .NET 2.0 con algunos ensamblados adicionales y 3.5 agrega algunos ensamblados más.Así, por ejemplo, .NET 3.5 agrega el DataPager control, que es un control web y debe agruparse en System.Web.UI.WebControls.Si los espacios de nombres y las ubicaciones físicas fueran idénticos, no podría ser porque están en un ensamblado diferente.

Entonces, tener espacios de nombres como entidades lógicas independientes significa que puede tener miembros de varios ensamblajes diferentes que están todos agrupados lógicamente porque están destinados a usarse en conjunto entre sí.

(Además, no hay nada de malo en que los diseños físicos y lógicos sean bastante similares).

De hecho, el entorno .Net le permite lanzar su código al IDE/sistema de archivos como espaguetis contra una pared.

Sin embargo, eso no significa que este enfoque sea sensato.Generalmente es una buena idea seguir con el enfoque proyecto.nombrecarpeta.Clase que se mencionó anteriormente.También es una muy buena idea mantener todas las clases de un espacio de nombres en la misma clase.

En Java, también puedes hacer cosas complicadas como esta y obtener toda la "flexibilidad" que deseas, pero las herramientas tienden a desaconsejarlo.Honestamente, una de las cosas más confusas para mí al conocer el mundo .Net fue cuán descuidado/inconsistente puede ser esto gracias a la guía relativamente pobre.Sin embargo, es fácil organizar las cosas de forma sensata con un poco de reflexión.:)

la diferencia es que los espacios de nombres .net no tienen mucho que ver con los paquetes java.

Los espacios de nombres .net sirven exclusivamente para gestionar el alcance declarativo y no tienen nada que ver con archivos, proyectos o sus ubicaciones.

Es muy simple todo lo declarado en un espacio de nombres en particular es accesible cuando incluye un 'uso' de ese espacio de nombres.

muy fácil.

La elección del nombre y si o no/cuántos '.' Los separadores que usas depende completamente de ti.

VS por defecto agrega .foldernames a sus espacios de nombres solo para intentar ser útil.

Este artículo explica bastante bien los espacios de nombres:http://www.blackwasp.co.uk/Namespaces.aspx

También tiene un ejemplo de convención de nomenclatura hacia el final, ¡aunque tu convención de nombres es tu decisión!;)

Dicho esto, la mayoría de los lugares en los que he trabajado y las personas con las que he trabajado comienzan con el nombre de la empresa, lo cual es sensato, ya que hace que los nombres de esa empresa sean distintos (separados de otros, bibliotecas, proveedores, proyectos de código abierto, etc.)

Puede agregar carpetas a su solución para cada espacio de nombres.Si bien aún se compilará en un único ejecutable, organiza los archivos fuente y proporciona (lo que creo que es) el efecto deseado.

Normalmente agrego una carpeta para cada espacio de nombres en mi proyecto y los anido según la misma jerarquía (MyApp.View.Dialogs, por ejemplo).

Los espacios de nombres son puramente semánticos.Si bien normalmente reflejan una estructura de carpetas, al menos cuando se utiliza Visual Studio IDE, no es necesario.

Puede hacer referencia al mismo espacio de nombres en varias bibliotecas, feo pero cierto.

Siempre he considerado la organización del archivo fuente y la asignación de identificadores a clases y objetos como dos problemas separados.Tiendo a mantener las clases relacionadas en grupos, pero no todos los grupos deberían ser un espacio de nombres.Los espacios de nombres existen (más o menos) para resolver el problema de los conflictos de nombres: en lenguajes de espacios de nombres planos como C, no se puede caminar dos pies sin tropezar con identificadores como mycompany_getcurrentdate o MYCGetCurrentDate, porque el riesgo de un conflicto con otra función en una biblioteca de terceros (o del sistema) es mucho menor.Si creara un paquete o espacio de nombres para cada separación lógica, obtendría (ejemplo de Java) nombres de clase como java.lang.primitivewrapper.numeric.Integer, lo cual es bastante excesivo.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top