2009-07-06 23 views
2

異なるソースからデータをインポートする必要のあるアプリケーションがある状況を想像してください。これらの各ソースには、別々のモデルが存在します(しばしば他のモデルとは関係ない)。名前空間内のグループ化とプレフィックスクラス

私はすべてのインポートを実行するソフトウェアコンポーネント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 

いくつかの種類の仕事をどう思いますか

あなたはどんな命名規則を守っていますか?このため

+0

私たちの言語は何ですか? –

+0

この場合のc#は、cファミリ(c、C++、c#、objective-c、java ..)でもかまいません。 –

+0

名前空間はありません。 – Zifre

答えて

2

を持っているでしょう、私は2番目のスタイルを好む(例えばX.Xls.Parser)。私はできるだけ分けて別々のコンポーネントを保つのが好きです。

これらは、これらのコンポーネントがどの程度密接に関連しているかによっても異なります。それらが非常に密接に関連している場合、それらは同じ名前空間内にあるはずです。

1

私はおそらく

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

、多分

X.Core.ParserBase 

または

X.IParser 

など個人的に

2

私はあなたの最後のオプションのために行くだろう:

Xls.XlsParser 
Csv.CsvParser 

これは、あなたの関連するクラスは、名前空間ごとにグループ化されてそのようにADO.NET規則

SqlClient.SqlConnection 
OracleClient.OracleConnection 

に似ていますが、あなたは2をインポートする場合コード内の名前空間を明示的に前置することによって区別する必要のない名前空間。

+0

Excelは.xls以外のファイル形式を扱うことができるため、特に.xlsファイル用のパーサーではXlsを使用します。 –

+0

特に2003年版と2007年版との間のフェアポイント。 –

+0

非常に合理的な答え。 –

0

私はまた、名前空間の使用に投票します。それが彼らのためのものです。

Intellisenseは、名前空間に分割すると便利です。