中規模大規模プロジェクトの構造

Question

私は初心者のプログラマーです。どんな愚かさに対しても謝ります。

少数のクラスだけで小さなプロジェクトを作成するPythonの背景から来たので、私はすべてのコードを1つのファイルに入れておくのが普通です。

私は最近C＃を学んでいましたが、私は相当に大きなコンソールアプリケーション（10,000行+）を書いています。私は明らかにすべてを1つのファイルに入れることはできませんが、プロジェクトをより小さなセグメントに分割する方法についてはわかりません。

私がこれまで行ってきたことは、ソリューション内の各名前空間に対して新しいプロジェクトを作成し、それに応じて各クラスを別々のファイルに分割することです。これまでのところ、私は約4つの名前空間を持っています。私は、それぞれの名前空間を別々に書いており、それぞれの名前空間を他のプロジェクトで使うようにしています。

ここで私はコンソールアプリケーションを構築するために各名前空間をまとめたいと思います。これをどうやって行うのですか？

また、正しい方法でコードを構成していますか？

また、プロジェクト内の完全に異なるディレクトリにあるファイルを使用することは可能ですか？

事前に感謝します。

Answer 1

あなたがで始まります名前空間を使用する場合は、通常、会社名や組織名（「A」など）を使用します。複数の製品やプロジェクトがあり、そのアイテムのコードを作成している場合は、修飾子（たとえば、 "B"、 "C"など）を追加して、A.B、A.Cなどを追加します。

次に、一般的なアプローチでは、関連するタイプの名前空間をグループ化する必要があります。タイプを作成し、それが一般的な問題に対する汎用/ユーティリティ/一度限りの解決策である場合は、より広いスコープの名前空間に保つ必要があります。いくつかの機能や目的をサポートするためにいくつかの型を作成しているのを見つけたら、それらの型を含むための狭い名前空間を作成することができます。たとえば、データ転送オブジェクト、データアクセスオブジェクトなどを含むA.Bのデータアクセスコンポーネントをいくつか記述する必要があるとします。これらの型をA.B.DataAccessのようなものに入れることをお勧めします。

ただし、.NETではOOPパラダイムを使用しています。 1つのOOPパラダイムはコードの再利用です。したがって、A.BとA.Cの両方のデータにアクセスする場合は、再利用可能なデータアクセスコンポーネントを作成して、両方のプロジェクトでコードを再利用するようにしてください。その場合、AB、ACなどで利用できる一般的な使用法、一般的な概念、または抽象的な概念を含む、あなたの製品で使用されている一般的な種類を含むA.Commonなどのプロジェクトを持つことができます。

この例を試してみましょう。

• プロジェクト：A.Common（アセンブリの名前）
• 目的：任意のプロジェクト
• 名前空間のための再利用可能なタイプ：A、A.DataAccess
• タイプ：A.DataAccess.DataAccessObjectBase

---

• プロジェクト：AB（アセンブリの名前）
• 目的：A.Commmon
• 名前空間：製品 "B"
• 参照のタイプA、AB、ABDataAccess
• タイプ：ABDataAccess.DataAccessObject（実装A.DataAccess.DataAccessObjectBase）

---

• プロジェクト：AC（アセンブリの名前）
• 目的：製品のタイプ "C"
• 参照：A.Common
• 名前空間：できれば、かなり単純化し、粗例ですACDataAccess.DataAccessObject（A.DataAccess.DataAccessObjectBaseを実装）

、しかし：A、AC、ACDataAccess

タイプアセンブリと名前空間の関係を視覚化するのに役立ちます。

他のいくつかのヒント：

• は、それが賢明な場合を除き、（例えばA.B.Something.SomeMoreStuff.EvenMoreStuffなど）の深い名前空間を作成する場合は特に、名前空間を作成して船外に行ってはいけません。それはあなたが物事を見つけるのが少し難しくなります。
• 名前空間は、幅広い目的から狭い目的に進むべきです。さらに、より広い名前空間のものに大きく依存する、より狭い名前空間に型を作成する場合は、より広範な名前空間に配置するようにしてください。例えばA.B.Broader.Narrower。

最後に、ソースファイルごとに1つのタイプのみを作成し続ける必要があります。

Answer 2

最後に質問から始めます。プロジェクト内の完全に異なるディレクトリにあるファイルを使用できます。私はあなたが正しい方法で行くと思う。異なる名前空間についてこのコードを使用することができます

using System; 
using namespace1; 
using namespace2; 

Answer 3

右のトラックには多少の響きがあります。あなたの質問/構造に対処する：

1）独自の名前空間をそれぞれのプロジェクトで表す必要はありません。クラスを構成するのに役立つならば、同じプロジェクト内に複数のサブネームスペースを持つことができます（そうする必要があります）。あなたのケースでは、それぞれが独自のスタンドアロンコンポーネントとしてプログラムされているように聞こえるので、それぞれのプロジェクトが意味を成しています。

2）各クラスを別々のファイルに分割しても問題ありません。

3）あなたのコードをつなぎ合わせることについて何を求めているのかよく分かりません。 Visual Studioでプロジェクトを物理的に参照/リンクする方法や、APIをコード化/アクセスするためのベストプラクティスをどのように行うのかを意味しますか？前者の場合は、プロジェクトの下にある「参照」項目を右クリックし、プロジェクトを指し示すことができます（コンパイルされたDLLではなく）。後者の場合、さまざまなプログラミングパターンがありますが、一般的には、プロジェクトの中から素敵なAPIを抽象化して、コードの内部的な動作に気を配りたくないでしょう。

4）まったく別のディレクトリからファイルを参照できます。プロジェクトやフォルダを右クリックし、 "Add - > Existing Item"を選択してファイルを参照してください。 http://msdn.microsoft.com/en-us/library/9f4t9t92%28VS.80%29.aspx

ここでは可能な解決策構造にビットを行く別のStackOverflowの質問があります：あなたは、おそらくそれは物理的にファイルをコピーしないように、「リンク」として追加することをお勧めしますSolution: Per application, or per application suite

Answer 4

名前空間は、コードを整理してseparation of concernsを提供するのに役立ちます。また、フォルダを作成したり、別のプロジェクトを作成したりすることもできます。優れたロジック分離を使用すると、保守可能でスケーラブルなアプリケーションを構築できます。

新しいフォルダを作成するか新しいプロジェクトを作成するかを決定するときには、常識に頼るべきです。たとえば、hello worldアプリケーションのいくつかのプロジェクトを作成することは過度のことです。 1つのクラスのフォルダを作成することはあまりにも大変です。しかし、互いに密接に関連したいくつかのクラスがある場合は、この特定の問題を他のアプリケーションと区別することを検討してください。例えば。 CustomerRepositoryがある場合は、OrderRepositoryとVendorRepositoryを追加します。彼らが代表している懸念を強調する良い決定。 Repositoriesフォルダを作成し、そこにあるすべてのクラスを移動します。

大規模なアプリケーションでは、ビジネスロジック、データアクセスロジック、ユーザーインターフェイスなどの懸念事項を分離するのが一般的です。通常、これらの懸案事項に関連するクラスは別々のプロジェクトに分かれています。コードを分かりやすく理解しやすくするために、分離が行われたことに留意してください。だから、名前空間はあなたとあなたのアプリケーションを維持する人に懸念を記述するべきです。例えば。

FooCompany.BLL 
FooCOmpany.DAL 
FooCOmpany.UI 

これは、ビジネスロジックレイヤー、データアクセスレイヤー、ユーザーインターフェイスの頭字語です。 「標準」の名前はありません。あなたは、あなたのコードをよりよく記述するものを使うことができます。あなたが開発している会社の名前と名前空間名を開始する

// Assembly for business logic 
Foo.Bar.Domain 
Foo.Bar.Domain.Model 
Foo.Bar.Domain.Services 
Foo.Bar.Domain.Repositories 
// Assembly for data access 
Foo.Bar.Persistence.NHibernate 
// Assembly for application services 
Foo.Bar.Services 
// Project for presentation  
Foo.Bar.Presentation.Web 
Foo.Bar.Presentation.Web.Controllers 
Foo.Bar.Presentation.Web.Views 

ところで一般的な方法：ここで私は普通の会社のFoo製品バーに使用するプロジェクト構造の例があります。 Namespace Naming Guidelinesを参照してください。これにより、異なる名前空間に同じ名前の2つのクラスがある場合、名前の競合を避けることができます。