私はASP.NET MVCプロジェクトを使用しています。クラスにフォルダを追加するたびに、実際には長い名前空間が作成されます。C＃のネームスペース
例：
Project = Tully.Saps.Data
Folder = DataAccess/Interfaces
Namespace = Tully.Saps.Data.DataAccess.Interfaces
Folder = DataAccess/MbNetRepositories
Namespace = Tully.Saps.Data.DataAccess.MbNetRepositories
質問：
はそれだけでは、名前空間を残し、それをアクセスするクラスに使用して句を追加したり、Tully.Saps.Dataに名前空間を変更するのが最善ですこのプロジェクトのすべてについては？
単独で使用してください。そのようなものを手動で変更することは困難です（デバッグが難しく、他のプロジェクトと矛盾するなど）。
本当にあなたがそれに対処する方法はあなた次第です。ネームスペースのメンバに1回か2回しかアクセスしない場合は、 "using"ステートメントを追加することは本当にあまり効果がありません。
これを複数回使用する場合は、ネームスペースチェーンを小さくすると、読みやすくすることになるでしょう。
新しい名前空間を作成せずにファイルを論理的にグループ化する場合は、常に新しい名前を追加するように名前空間を変更できます。 FxCopのによると
、と私は同意する：いくつかの種類と
避け名前空間は
名前空間は、一般的により種類を持っている必要があります。また
（これは "単一の名前空間" の提案に適用されます - ノーネームスペースとして言ってほとんど同じである）の名前空間
Aで
宣言タイプ重複を避けるために名前空間内に型を定義する必要があります。
.Namespacesは、私たちは私たちのオブジェクトモデルまたは当社のアプリケーションにエンティティのセットの「範囲」を定義するのに役立ちます。これにより、フォルダー構造の決定ではなく、ソフトウェア設計の決定になります。たとえば、MVCアプリケーションでは、Model/View/Controllerフォルダと関連する名前空間を持つことが理にかなっています。したがって、フォルダー構造が開発で使用することに決めた名前空間パターンと一致することは可能ですが、それは必須ではなく、私たちが望むものではないかもしれません。各名前空間は、名前空間のステートメントを使用して定義する文
を使用して、ケース・バイ・ケースの決定
お待ちください。これは、IDEがコーディングスタイルをどのように指定しているかの素晴らしい例です。
あなたが使用しているツール（Visual Studio）が、各フォルダが新しい名前空間を必要としていると判断したとしても、それは意味しません。
私は個人的に私の "データ"プロジェクトを単一の名前空間として残しがちです。 "Model"という名前のサブフォルダがある場合、Something.Data.Model名前空間にそれらのファイルを入れたくないので、Something.Dataにそれらのファイルを入れてください。