2

想象这样一种情况,您有一个需要从不同来源导入数据的应用程序。对于这些来源中的每一个都存在一个单独的模型(通常与其他来源无关)。

所以假设我有我的软件组件 X,它负责所有的导入,命名空间相应地是 X。在 X 中,我有所有不同的解析器和导入器,所以可能一个用于 txt 文件,另一个用于 xls 文件等。

你更喜欢哪种风格:

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

对比

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

还是我应该将相应源的模型(2-4 个实体)放入子命名空间?

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

我不想用所有那些不相关的类将单个命名空间弄乱,但是我也不想遇到诸如弄清楚我的代码正在引用哪个解析器之类的问题(必须查看 usings)。

你有什么想法

X.Xls.XlsParser

某种双倍的工作。

您遵守哪些命名约定?

4

4 回答 4

2

就个人而言,我更喜欢第二种风格(例如X.Xls.Parser)。我喜欢尽可能分开单独的组件。

这还取决于这些组件的相关程度。如果它们非常密切相关,它们应该在同一个命名空间中。

于 2009-07-06T14:07:07.053 回答
2

我会选择你的最后一个选择:

Xls.XlsParser
Csv.CsvParser

这类似于 ADO.NET 约定

SqlClient.SqlConnection
OracleClient.OracleConnection

这样,您的相关类将按命名空间分组,但如果您导入 2 个命名空间,则无需通过在代码中显式添加命名空间前缀来区分。

于 2009-07-06T14:16:56.027 回答
1

为此,我可能会有

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

有可能

X.Core.ParserBase

或者

X.IParser

等等

于 2009-07-06T14:04:56.027 回答
0

我也会投票赞成使用命名空间。这就是他们的目的。

如果您将事物分解为命名空间,智能感知将更加有用。

于 2009-07-06T14:18:56.897 回答