Nº
que he probado ambos métodos en proyectos pequeños y grandes, tanto con el solo (yo) y un equipo de desarrolladores.
Encontré que la ruta más simple y más productiva era tener un solo espacio de nombres por proyecto y todas las clases entran en ese espacio de nombres. Ahora puede colocar los archivos de clase en las carpetas de proyectos que desee. No hay problema con la adición de instrucciones de uso en la parte superior de los archivos, ya que solo hay un único espacio de nombres.
Es importante organizar los archivos de origen en carpetas y en mi opinión para eso se deben usar todas las carpetas. Exigir que estas carpetas también se asignen a espacios de nombres es innecesario, crea más trabajo, y encontré que era realmente perjudicial para la organización porque la carga adicional fomenta la desorganización.
Tome esta advertencia FxCop por ejemplo:
CA1020: Evitar espacios de nombres con unos tipos
causa: Un espacio de nombres que no sea el espacio de nombres global contiene menos de cinco tipos https://msdn.microsoft.com/en-gb/library/ms182130.aspx
Esta advertencia alienta el volcado de archivos nuevos en una carpeta genérica Project.General, o incluso en la raíz del proyecto hasta que tenga cuatro clases similares para justificar la creación de una ne w carpeta. ¿Eso sucederá alguna vez?
Búsqueda de archivos
La respuesta aceptada dice: "Las clases serán más fáciles de encontrar y que solamente debe haber razones lo suficientemente bueno."
Sospecho que la respuesta se refiere a tener múltiples espacios de nombres en un proyecto que no se asignan a la estructura de carpetas, en lugar de lo que estoy sugiriendo que es un proyecto con un solo espacio de nombres.
En cualquier caso, aunque no pueda determinar en qué carpeta está un archivo de clase desde el espacio de nombres, puede encontrarlo usando Ir a definición o el cuadro de búsqueda del explorador de solución en Visual Studio. Además, este no es realmente un gran problema en mi opinión.No gasto ni el 0.1% de mi tiempo de desarrollo en el problema de encontrar archivos para justificar la optimización.
Nombre choca
Claro crear varios espacios de nombres permite proyecto tenga dos clases con el mismo nombre. ¿Pero eso realmente es algo bueno? ¿Es quizás más fácil simplemente no permitir que eso sea posible? Permitir dos clases con el mismo nombre crea una situación más compleja en la que el 90% del tiempo las cosas funcionan de cierta manera y de repente te das cuenta de que tienes un caso especial. Digamos que tiene dos clases rectángulo definido en espacios de nombres distintos:
- clase Project1.Image.Rectangle
- clase Project1.Window.Rectangle
Es posible golpear a un problema que un archivo de fuente necesita incluir ambos espacios de nombres. Ahora usted tiene que escribir el espacio de nombres completo por todas partes en ese archivo:
var rectangle = new Project1.Window.Rectangle();
O enredar con algo desagradable using:
using Rectangle = Project1.Window.Rectangle;
Con un único espacio de nombres en el proyecto que se ven obligados para llegar con diferente, y yo diría más descriptivo, nombres como esto:
- clase Project1.ImageRectangle
- clase Project1.WindowR rectángulo
Y el uso es el mismo en todas partes, no tiene que ocuparse de un caso especial cuando un archivo utiliza ambos tipos.
utilizando declaraciones
using Project1.General;
using Project1.Image;
using Project1.Window;
using Project1.Window.Controls;
using Project1.Shapes;
using Project1.Input;
using Project1.Data;
vs
using Project1;
La facilidad de no tener que añadir espacios de nombres todo el tiempo, mientras que la escritura de código. No es el tiempo que realmente toma, es la interrupción en el flujo de tener que hacerlo y solo llenar los archivos con muchas declaraciones de uso, ¿para qué? ¿Vale la pena?
Cambio de estructura de carpetas del proyecto
Si las carpetas se asignan a los espacios de nombres a continuación, la ruta de la carpeta proyecto está efectivamente en forma fija en cada archivo fuente. Esto significa que cualquier cambio de nombre o movimiento de un archivo o carpeta en el proyecto requiere que se modifique el contenido real del archivo. Tanto la declaración del espacio de nombres de los archivos en esa carpeta y el uso de las declaraciones en un montón de otros archivos que hacen referencia a las clases en esa carpeta. Si bien los cambios en sí mismos son triviales con las herramientas, generalmente resultan en una confirmación grande que consta de muchos archivos cuyas clases ni siquiera han cambiado.
Con un solo espacio de nombre en el proyecto puede cambiar la estructura de la carpeta del proyecto como desee sin que se modifiquen los archivos de origen.
Visual Studio asigna automáticamente el espacio de nombres de un nuevo archivo en la carpeta del proyecto se crea en
desafortunado, pero encuentro la molestia de corregir el espacio de nombres es inferior a la molestia de tratar con ellos. También tengo el hábito de copiar pegando un archivo existente en lugar de usar Agregar-> Nuevo.
Intellisense y Examinador de objetos
El mayor beneficio en mi opinión de la utilización de múltiples espacios de nombres en grandes proyectos es tener organización adicional durante la visualización de las clases en cualquier herramienta que muestra las clases en una jerarquía de espacios de nombres. Incluso documentación. Obviamente, tener solo un espacio de nombres en los resultados del proyecto en todas las clases se muestra en una sola lista en lugar de dividirse en categorías. Sin embargo, personalmente, nunca me ha sorprendido o retrasado debido a la falta de esto, así que no creo que sea un beneficio lo suficientemente grande como para justificar múltiples espacios de nombres.
Aunque si estuviera escribiendo una gran biblioteca de clase pública, entonces sería probablemente utilice varios espacios de nombres en el proyecto para que el conjunto se vea limpio en las herramientas y la documentación.
Nota: ReSharper se quejará si los espacios de nombres no coinciden con la jerarquía de carpetas. – Fred