¿Está bien:¿Está bien tener un nombre de espacio de nombres que exista en dos puntos del árbol?
namespace Simple.OData
{
// Common OData functionality
}
namespace Simple.Data.OData
{
// The Simple.Data adapter for OData
}
Se siente como que podría estar equivocado, pero no estoy seguro.
Es ciertamente válido - considere System.Xml.Linq y System.Linq. No puedo prever inmediatamente ningún problema ... pero eso no quiere decir que es necesariamente una buena idea.
personalmente prefiero Simple.Data.OData sobre Simple.OData.Data, como sospecho que esto está dirigido principalmente a personas que están usando Simple.Data, pero sucede utilizar OData - no personas que están enfocados en OData. De nuevo, esto es como LINQ: System.Xml.Linq es una API XML que funciona con LINQ; no es un "proveedor" de LINQ como tal.
Básicamente es el mismo tipo de problema que "Tengo un convertidor para convertir de tipo A a tipo B, ¿lo pongo cerca de tipo A o tipo B?" - pero con espacios de nombres.Mi experiencia es que usualmente más rascado de cabeza entra en pensar en lo mejor que se puede hacer que en los problemas que podría causar al tomar cualquiera de los enfoques ...
Me preguntaba por qué originalmente no se consideraba "System.Linq.Xml" en lugar de "System.Xml.Linq" , para mí, parece más claro – sll
Probablemente existe en el ensamblado 'System.Xml', en lugar del' System.Linq' –
@sllev: Estaba agregando un comentario en ese sentido, fundamentalmente es una API XML. Lo usa cuando quiere trabajar con datos XML, y resulta que funciona bien con LINQ. –
Más correcto sería, namespace Simple.OData.Data.
Esto se debe a que el espacio de nombres Data se debe agrupar con las otras clases relacionadas con OData.
Si usted está pensando, junto con las líneas de System.Data, System.Data.SqlClient entonces es más o menos porque son una parte del conjunto System.Data.dll, y son una parte integral de la misma. Mi propia implementación de las clases IDbCommand etc. vive en el espacio de nombres MyNamespace.SubNamespace.AdoWrapper, si eso le da algún contexto.
En su caso, Simple.Data presumiblemente no existe o tiene mucho en él, a diferencia de System.Data ..
+1 pero hubiera sonado más fresco como "espacio de nombres más simple Simple.OData.Data sería, joven Padawan": p – Kheldar
Sí, lo es, pero hay algunos inconvenientes.
El espacio de nombre es parte del nombre del tipo. Es decir, un tipo denominado C dentro del espacio de nombres A.B, se llama actualmente A.B.C.
Cuando utiliza la instrucción using, está utilizando un tipo de atajo .
inconvenientes:
he notado que a veces Visual Studio puede llegar a ser poco confuso, especialmente cuando se utilizan espacios de nombres tales como System, y otros que existen en el marco .Net ... de tal manera que se debe ingresar el nombre completo del tipo.
Puede ser confuso para algunas personas, pero no debería causar ningún problema. Usted va a necesitar para antepóngale el espacio de nombres, aunque si escribe esto:
using Simple.Odata;
using Simple.Data.Odata;
lo contrario, la compilación no lo reconocerá. Probablemente haya una estructura mejor para lo que estás tratando de crear, pero para responder a tu pregunta: sí, está bien hacerlo si quieres.
Claro que sí, si es semánticamente correcto. ¡Mira cuántos espacios de nombres de marcos terminan en .Design, por ejemplo!
La última parte debe depender de la (s) parte (s) anterior (es) del espacio de nombres. Su adaptador tiene una dependencia con Simple.OData pero también con Simple.Data. Pero desde Simple.OData es menos genérico que prefiero algo como:
using Simple.Data
namespace Simple.OData.Adapters
{
// The Simple.Data adapter for OData
}
[Este otro mensaje] (http://stackoverflow.com/questions/918894/namespace-naming-conventions/918913#918913) dan usted un enlace con las pautas de nombres namaspaces. – JPBlanc