No.
He probado ambos métodos en proyectos pequeños y grandes, tanto con un solo (yo) como con un equipo de desarrolladores.
Encontré que la ruta más simple y productiva era tener un solo espacio de nombres por proyecto y todas las clases van a ese espacio de nombres. A continuación, puede colocar los archivos de clase en las carpetas de proyectos que desee. No hay ningún problema con agregar declaraciones de uso en la parte superior de los archivos todo el tiempo, ya que solo hay un espacio de nombres único.
Es importante organizar los archivos fuente en carpetas y, en mi opinión, para eso deben usarse todas las carpetas. Exigir que estas carpetas también se asignen a espacios de nombres es innecesario, crea más trabajo y descubrí que en realidad era perjudicial para la organización porque la carga adicional alienta la desorganización.
Tome esta advertencia de FxCop por ejemplo:
CA1020: Evite los espacios de nombres con pocos tipos de
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 nuevos archivos en una carpeta genérica Project.General, o incluso la raíz del proyecto hasta que tenga cuatro clases similares para justificar la creación de una nueva carpeta. ¿Sucederá eso alguna vez?
Encontrar archivos
La respuesta aceptada dice "Las clases serán más fáciles de encontrar y eso solo debería ser una razón suficientemente buena".
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, si bien no puede determinar en qué carpeta se encuentra un archivo de clase desde el espacio de nombres, puede encontrarlo utilizando Ir a definición o el cuadro del explorador de soluciones de búsqueda en Visual Studio. Además, esto no es realmente un gran problema en mi opinión. No gasto ni siquiera el 0.1% de mi tiempo de desarrollo en el problema de encontrar archivos para justificar la optimización.
Choques de nombres
Claro que crear múltiples espacios de nombres permite que el proyecto tenga dos clases con el mismo nombre. ¿Pero es eso realmente algo bueno? ¿Es quizás más fácil simplemente evitar que eso sea posible? Permitir dos clases con el mismo nombre crea una situación más compleja en la que el 90% de las veces las cosas funcionan de cierta manera y de repente descubres que tienes un caso especial. Supongamos que tiene dos clases de Rectángulo definidas en espacios de nombres separados:
- clase Project1.Image.Rectangle
- clase Project1.Window.Rectangle
Es posible encontrar un problema que un archivo de origen necesita incluir ambos espacios de nombres. Ahora tiene que escribir el espacio de nombres completo en todas partes en ese archivo:
var rectangle = new Project1.Window.Rectangle();
O jugar con alguna declaración desagradable usando:
using Rectangle = Project1.Window.Rectangle;
Con un solo espacio de nombres en su proyecto, se ve obligado a crear nombres diferentes, y diría que son más descriptivos, como este:
- clase Project1.ImageRectangle
- clase Project1.WindowRectangle
Y el uso es el mismo en todas partes, no tiene que lidiar con un caso especial cuando un archivo usa ambos tipos.
usando 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 agregar espacios de nombres todo el tiempo al escribir código. Realmente no es el tiempo que toma, es la interrupción en el flujo de tener que hacerlo y simplemente llenar archivos con muchas declaraciones de uso, ¿para qué? ¿Vale la pena?
Cambiar la estructura de la carpeta del proyecto
Si las carpetas se asignan a espacios de nombres, la ruta de la carpeta del proyecto está efectivamente codificada en cada archivo de origen. Esto significa que cualquier cambio de nombre o movimiento de un archivo o carpeta en el proyecto requiere que el contenido real del archivo cambie. Tanto la declaración del espacio de nombres de los archivos en esa carpeta como el uso de declaraciones en un montón de otros archivos que hacen referencia a clases en esa carpeta. Si bien los cambios en sí mismos son triviales con las herramientas, generalmente resultan en una gran confirmación que consta de muchos archivos cuyas clases ni siquiera han cambiado.
Con un solo espacio de nombres en el proyecto, puede cambiar la estructura de carpetas del proyecto como lo desee sin modificar los archivos fuente.
Visual Studio asigna automáticamente el espacio de nombres de un nuevo archivo a la carpeta del proyecto en el que se creó
Desafortunadamente, pero encuentro que la molestia de corregir el espacio de nombres es menor que la molestia de tratar con ellos. También tengo la costumbre de copiar y pegar un archivo existente en lugar de usar Agregar-> Nuevo.
Intellisense y buscador de objetos
El mayor beneficio en mi opinión de usar múltiples espacios de nombres en grandes proyectos es tener una organización adicional al ver las clases en cualquier herramienta que muestre clases en una jerarquía de espacios de nombres. Incluso documentación. Obviamente, tener solo un espacio de nombres en el proyecto da como resultado que todas las clases se muestren en una sola lista en lugar de dividirse en categorías. Sin embargo, personalmente nunca me he quedado perplejo o retrasado debido a la falta de esto, por lo que no considero 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 , probablemente usaría múltiples espacios de nombres en el proyecto para que el ensamblaje se vea bien en las herramientas y la documentación.