Grouping in a namespace vs. prefixing Classes

Question

Hi,

imagine a situation where you have an application that needs to import data from different sources. For each of these sources exists a seperate model (often not related to the others).

So let's say i have my software component X which does all the importing, the namespace is correspondingly X. In X i have all my different parsers and importers, so maybe one for txt files, another for xls files etc.

Which style do you prefer:

X.XlsParser
X.XlsModelObject
X.TxtParser
X.TxtModelObject

vs.

X.Xls.Parser
X.Xls.ModelObject
X.Txt.Parser
X.Txt.ModelObject

or should i just put the model (2-4 entities) for the corresponding source into a sub namespace?

X.XlsParser
X.Xls.ModelObjectA
X.Xls.ModelObjectB
X.TxtParser
X.Txt.ModelObjectA
X.Txt.ModelObjectB

I don't want to clutter a single namespace with all those unrelated classes, however i also don't want to have issues like figuring out which parser my code is referencing (would have to look usings).

What do you think about

X.Xls.XlsParser

some kind of doubles the work.

What naming conventions do you adhere to?

Answer 1

For this I would probably have

X.Excel.Parser
X.Excel.ModelObject
X.Csv.Parser
X.Csv.ModelObject

and maybe

X.Core.ParserBase

or

X.IParser

etc.

Answer 2

Personally, I prefer the second style (e.g. X.Xls.Parser). I like to keep separate components as separated as I can.

It also depends on how closely related these components are. If they are very closely related, they should be in the same namespace.

Answer 3

I would go for your last option:

Xls.XlsParser
Csv.CsvParser

This is similar to ADO.NET conventions

SqlClient.SqlConnection
OracleClient.OracleConnection

That way, your related classes are grouped by namespaces, but if you import 2 namespaces you don't need to differentiate by explicitly prefixing with the namespace in your code.

Answer 4

I would also vote for using namespaces. That's what they are for.

Intellisense will be more useful if you break things up into namespaces.