ここで疑問に思っていたのは、機能、範囲などの観点から、プロジェクトをどのように整理しているのかということです.
単体テスト用に 1 つのプロジェクト、クラス ライブラリ コード用に 1 つのプロジェクト、ユーザー インターフェイス用に 1 つのプロジェクトがありますか?
それとも、これらすべてを別々のフォルダーに分割しますか?
中央のコード ライブラリは 1 か所にあり、UserInterface (WinForms の依存関係なし) または UnitTests への直接参照がないため、プロジェクトごとにこれらを分離する方が簡単だと考えていました。
ご意見はありますか？
私は、プロジェクトをいわゆる「展開単位」に分割しようとしています。つまり、「これらのアセンブリを展開するにはどうすればよいか?」
私は明らかに単体テストを展開していないので、それらは独自のプロジェクトにあります。
I then divide UI and "business logic" into separate projects. If I keep those lines of separation clean, I can replace my UI layer with a new technology or infrastructure (think WPF vs. ASP.NET) and still reuse the "business logic" assemblies for both. I just introduce a new UI layer that understands the business logic interface.
I also try to keep a separate library for code that I might share between solutions. This would be my data access utilities, file parsing utilities, and others that I use over and over as I build projects. I can just include those assemblies into my new solutions and I get all of that functionality that I've already invested my time in.
Hope that helps.
ソリューション内でプロジェクトを整理するのに役立つと思ったいくつかのパターン：
私はほとんどの場合、「common」または「utils」プロジェクトを持っています。このプロジェクトには依存関係がほとんどないはずなので、私のソリューション（またはおそらく他のソリューション）のどこでもどこでも簡単に再利用できます。このプロジェクトに多くの小さなヘルパークラスが分類されることに驚かれることでしょう。
私は常にビジネスロジックを1つのプロジェクト（またはより可能性の高いプロジェクトのセット）に分割し、ブートストラップ/プロバイダーコードを別のプロジェクト（またはプロジェクトのセット）に分割しようとしています。私のブートストラップ/プロバイダークラスはコンテキスト固有です（HttpContextやコマンドライン引数などの存在を想定できます）が、ビジネスロジックは含まれていません。私のビジネスクラスはビジネスロジックを実装していますが、コンテキスト固有の要素の有無を想定していません。そうすれば、最初にシステムをコンソールアプリとして構築した場合、後でWindowsサービスのブートストラップ/プロバイダーのセットを作成し、ビジネスクラスへの影響を最小限に抑えてWindowsサービスにすばやく変換できます。
ブートストラップ/プロバイダークラスと同様に、データレイヤーをビジネスクラスから分離しようとしています。しかし、それは誰もが1000回聞いたことがある一般的な基本的な分離であるため、言及する価値はほとんどありません。
多くのシステムのビジネスロジックは複雑すぎて、単一のプロジェクトに収まらず、ある程度のコードの保守性を維持できません。したがって、私は通常、機能領域（「顧客管理」、「製品在庫」など）ごとにグループ化された複数のビジネスロジックプロジェクトを抱えています。
ソリューション内のプロジェクトに関しては、次のようになります。
管理-一般的なドキュメント、ライセンスのマスターコピーなど。通常、これを、ライセンスやリビジョンノートなどを表示する小さなコマンドラインの「readme」アプリケーションにコンパイルします。
データ-XMLなどの一般的なデータ。コンパイル可能なコードはありません。
Library1 ... LibraryN-1つ以上のライブラリ（通常は1〜3：utils、core、extended code）。
Application1 ... ApplicationN-アプリケーション（通常は1つ）。
Test1...TestN-テスト。
各プロジェクト内で、各名前空間のファイルを別々のフォルダーに保持し、サブ名前空間をサブフォルダーに保持します。ドキュメント、ライブラリまたはアプリ固有のデータ、埋め込みライセンステキストなどの一般的なタイプのものを保持します。プロジェクトに関係なく、同じ名前のサブフォルダー。
-ニール
私が関わってきた最近のいくつかのプロジェクト - 最終的に次の構造になりました (すべての WPF Prism プロジェクト):
xxx.Shell.Exe
xxx.yyyModule.dll (×4～7)
xxx.テスト
xxx.モデル
xxx.共通
WCF を使用する場合は、次を追加します。
xxx.バックエンド
xxx.DataContracts
オールインワン ソリューション (私たちは長いビルド時間に耐えています...) それを個別のソリューションに分割すると、リファクタリング時にあまりにも多くの問題が発生しました。これまでのところ、うまく機能しています。
Stack Overflow と Google で検索してみてください。同じ質問をした人が他にもいます。
いくつかの考慮事項:
Visual Studio では、1 つの大きなプロジェクトよりも、多数のプロジェクトを含むソリューションをコンパイルするのに時間がかかります。ソリューションを細かく分割しないでください。
Microsoft のComposite Application Guidanceには、プロジェクトを分割する興味深い方法があります。インフラストラクチャ プロジェクト、ブートストラップ プロジェクト、そしてコードの「モジュール」ごとのプロジェクトがあります。
現在、私はあなたの例のようにプロジェクトを分割するプロジェクトに取り組んでいます: インフラストラクチャ、ビジネス ロジック、GUI、単体テスト。
ファイルの種類ではなく、目的別にファイルを整理することを好みます。たとえば、「Events」と「Interfaces」ではなく、「Communication」と「Interop」というフォルダーを作成します。
単体テスト用に 1 つのプロジェクト、クラス ライブラリ コード用に 1 つのプロジェクト、ユーザー インターフェイス用に 1 つのプロジェクトがありますか?
かなりこれ。通常、UI をスリムに保ち、ビジネス ロジックを独自のプロジェクトに移動します。ビジネス ロジック プロジェクトごとに 1 つのテスト プロジェクトを作成します。
UI を備えたビジネスっぽいアプリケーションを実行している場合は、MVCを調べる必要があります。
もちろん、MVC は一般的な概念にすぎませんが、現在直面している種類の意思決定を支援するものです。
MVC in WPFには多くのリソースがあり、おそらく WinForms にも直接適用できます。
あなたが説明したように、私はアセンブリの種類ごとにプロジェクトを分割します。少なくとも、実行可能なメイン プロジェクト (アプリケーションの場合) と 1 つ以上のクラス ライブラリを用意しておくとよいでしょう。Windows アプリの場合は、UI をコードからできるだけ分離するようにしてください。WPF アプリは、それを実現する素晴らしい仕事をします。
それ以外に、コードの再利用が明白または明らかな場合は、いくつかのサードパーティ クラス ライブラリを収集し、独自のクラス ライブラリを作成することをお勧めします。