Deben las carpetas en una solución coincide con el espacio de nombres?

Question

Deben las carpetas en una solución coincide con el espacio de nombres?

En uno de mis equipos de proyectos, contamos con una biblioteca de clases que tiene muchos sub-carpetas en el proyecto.

Nombre del proyecto y el espacio de Nombres: MyCompany.Project.Section.

Dentro de este proyecto, hay varias carpetas que coincidan con la sección de espacio de nombres:

• Carpeta Vehicles tiene clases en la MyCompany.Project.Section.Vehicles espacio de nombres
• Carpeta Clothing tiene clases en laMyCompany.Project.Section.Clothing espacio de nombres
• etc.

Dentro de este mismo proyecto, es otro falso carpeta

• Carpeta BusinessObjects tiene clases en la MyCompany.Project.Section espacio de nombres

Hay un par de casos como este, donde carpetas, están hechos para la "organización de conveniencia".

Mi pregunta es:¿Cuál es el estándar?En la clase de bibliotecas de hacer las carpetas suelen coincidir con la estructura de espacio de nombres o es una mezcla de bolsa?

Answer 1

También, tenga en cuenta que si utiliza las plantillas integradas para añadir clases a una carpeta, por defecto se pone en un espacio de nombres que refleja la jerarquía de carpetas.

Las clases serán más fáciles de encontrar y que solo debe ser razones suficientes.

Las reglas a seguir son los siguientes:

• Proyecto/nombre del ensamblado es el mismo que el espacio de nombres raíz, excepto para el .dll que termina
• La única excepción a la regla anterior es un proyecto con una .Núcleo de terminar, el .Core es despojado
• Carpetas es igual a espacios de nombres
• Un tipo por cada archivo (de clase, estructura, enumeración, delegado, etc.) hace que sea fácil encontrar el archivo correcto

Answer 2

No.

Yo he probado ambos métodos en proyectos pequeños y grandes, ambos con una sola (me) y un equipo de desarrolladores.

He encontrado la manera más sencilla y productiva de la ruta iba a tener un único espacio de nombres por el proyecto y todas las clases de ir en ese espacio de nombres.Entonces eres libre de poner los archivos de clase en cualquier proyecto de carpetas que desea.No es cachondeo acerca de la adición de instrucciones de uso en la parte superior de los archivos de todo el tiempo como sólo hay un único espacio de nombres.

Es importante organizar los archivos de origen en carpetas y en mi opinión que todas las carpetas debe ser usado para.La exigencia de que las carpetas también el mapa de espacios de nombres es innecesario, crea más trabajo, y me encontré fue realmente perjudiciales para la organización debido a la carga adicional anima a la desorganización.

Tome este FxCop advertencia por ejemplo:

CA1020:Evitar espacios de nombres con unos tipos de
causa:Un espacio de nombres distinto del espacio de nombres global contiene menos de cinco tipos https://msdn.microsoft.com/en-gb/library/ms182130.aspx

Esta advertencia alienta el vertido de nuevo los archivos en un Proyecto genérico.Carpeta General, o incluso la raíz del proyecto hasta que tenga cuatro clases similares para justificar la creación de una nueva carpeta.Se que nunca suceda?

Búsqueda De Archivos

El aceptó la respuesta dice: "Las clases serán más fáciles de encontrar y que solo deben ser motivo lo suficientemente bueno."

Sospecho que la respuesta se refiere a tener varios espacios de nombres en un proyecto que no asignan a la estructura de la carpeta, en lugar de lo que estoy sugiriendo es que es un proyecto con un único espacio de nombres.

En cualquier caso, mientras que no se puede determinar la carpeta de un archivo de clase se encuentra en el espacio de nombres, se puede encontrar mediante el uso de Ir A Definición o la búsqueda en el explorador de soluciones cuadro en Visual Studio.También, esta no es realmente un gran problema, en mi opinión.Yo no gaste incluso 0.1% de mi tiempo de desarrollo en el problema de la búsqueda de archivos para justificar la optimización de la misma.

Nombre de enfrentamientos

Seguro de creación de múltiples espacios de nombres proyecto permite tener dos clases con el mismo nombre.Pero es que es realmente una buena cosa?Es tal vez más fácil simplemente no permitir que de ser posible?Permitir que dos clases con el mismo nombre, se crea una situación más compleja en donde el 90% de las veces las cosas funcionan de una determinada manera y de repente descubre que tiene un caso especial.Decir que hay dos Rectángulo clases definidas en distintos espacios de nombres:

• clase Project1.Imagen.Rectángulo
• clase Project1.De la ventana.Rectángulo

Es posible golpear a un problema en el que un archivo de origen debe incluir tanto los espacios de nombres.Ahora tienes que escribir el total de espacio de nombres en todas partes en ese archivo:

var rectangle = new Project1.Window.Rectangle();

O ensuciar alrededor con un poco desagradable instrucción de uso:

using Rectangle = Project1.Window.Rectangle;

Con un único espacio de nombres en el proyecto que se ven obligados a proponer diferentes, y yo diría que más descriptivo, nombres como esta:

• clase Project1.ImageRectangle
• clase Project1.WindowRectangle

Y el uso es el mismo en todas partes, usted no tiene que lidiar con un caso especial cuando un archivo utiliza ambos tipos.

instrucciones de uso

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, mientras que la escritura de código.No es el tiempo que se tarda realmente, es la ruptura en el flujo de tener que hacerlo y acaba de llenar los archivos con un montón de instrucciones de uso - para qué?¿Vale la pena?

El cambio de estructura de carpetas del proyecto

Si las carpetas se asignan a los espacios de nombres, a continuación, el proyecto de la ruta de la carpeta es, efectivamente, codificada en cada archivo de código fuente.Esto significa que cualquier cambio de nombre o mover un archivo o una carpeta en el proyecto requiere de real contenido del archivo a cambiar.Tanto la declaración de espacio de nombres de los archivos de esa carpeta y el uso de instrucciones en un montón de otros archivos que hacen referencia a clases en esa carpeta.Mientras que los cambios sí son triviales con herramientas, por lo general resulta en una gran cometer consta de varios archivos cuyas clases aún no ha cambiado.

Con un único espacio de nombres en el proyecto que puede cambiar la estructura de carpetas del proyecto, sin embargo usted desee sin ningún tipo de fuente de los archivos que han sido modificados.

Visual Studio automáticamente asigna el espacio de nombres de un archivo nuevo en la carpeta del proyecto que se ha creado en

Lamentable, pero me parece 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 pegar un archivo existente en lugar de usar Agregar->Nuevo.

Intellisense y el Explorador de Objetos

El mayor beneficio, en mi opinión de la utilización de múltiples espacios de nombres en los grandes proyectos que se tienen de la organización al ver las clases en las herramientas que muestra las clases en una jerarquía de los espacios de nombres.Incluso la documentación.Obviamente, disponer de un espacio de nombres en los resultados del proyecto en todas las clases que se muestran en una lista única vez de divide en categorías.Sin embargo, personalmente, nunca he sido confundido o retrasado debido a la falta de este no me parece un gran suficientes beneficios para justificar múltiples espacios de nombres.

Aunque si yo fuera a escribir un gran público de la biblioteca de clases luego me sería probablemente el uso de múltiples espacios de nombres en el proyecto para que la asamblea se veía limpia en las herramientas y la documentación.

Answer 3

Creo que el estándar, dentro de .NET, es tratar de hacerlo cuando sea posible, pero no para crear innecesariamente estructuras profundas sólo se adhieren a ella como una regla estricta.Ninguno de mis proyectos siguen el namespace == estructura de la regla de 100% de tiempo, a veces sólo de su limpiador/mejor salir de tales reglas.

En Java no tiene una elección.Yo diría que eso es un caso clásico de lo que funciona en la teoría vs lo que funciona en la práctica.

Answer 4

@lassevk:Estoy de acuerdo con estas reglas, y uno más para agregar.

Cuando tengo clases anidadas, todavía me split de ellos, uno por cada archivo.Como este:

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

y

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}

Answer 5

Yo diría que sí.

En primer lugar, será más fácil buscar los archivos de código por el siguiente hacia abajo de los espacios de nombres (es decir, cuando alguien te envía e-mails de un desnudo a excepción de la pila de llamadas).Si usted deja a sus carpetas de ir fuera de sincronización con los espacios de nombres, la búsqueda de archivos en las grandes lineas de codificación se convierte en llegar cansado.

Segundo, VS generará nuevas clases de crear en las carpetas con el mismo espacio de nombres de la carpeta principal de la estructura.Si usted decide nadar en contra de esta, va a ser uno más en el trabajo de plomería para hacer a diario cuando la adición de nuevos archivos.

Por supuesto, esto va sin decir que uno debe ser conservador acerca de cómo profundas en el mejor once de la carpeta/espacio de nombres de la jerarquía.

Answer 6

Sí que debería, sólo conduce a la confusión de lo contrario.

Answer 7

¿Cuál es el estándar?

No hay ninguna norma oficial pero convencionalmente la carpeta a la asignación de espacio de nombres patrón es el más ampliamente utilizado.

En la clase de bibliotecas de hacer las carpetas que normalmente coincide con el espacio de nombres estructura o es una mezcla de bolsa?

Sí, en la mayoría de las bibliotecas de clases de las carpetas coincide con el espacio de nombres organizacional de la facilidad.