Visual Studioソリューションのグッドプラクティス[終了]

うまくいけば、相対論の簡単な質問です。私は建物内の修理されたデバイスの扱いやすさを作成するための新しい内部プロジェクトに取り組んでいます。

データベースはリモートでウェブサーバーに保存され、ウェブAPI（JSON出力）を介してアクセスされ、OAuthで保護されます。フロントエンドGUIはWPFで、ビジネスコードはC＃で作成されています。

これから、プレゼンテーション/アプリケーション/データストアのさまざまなレイヤーがわかります。APIへのすべての認証済み呼び出し、エンティティ（ビジネスオブジェクト）を表すクラス、エンティティ（ビジネスオブジェクト）を構築するクラス、WPF GUIのパーツ、WPFビューモデルのパーツなどを管理するためのコードがあります。

これを単一のプロジェクトで作成するのが最適ですか、それとも個別のプロジェクトに分割するのが最適ですか？

私の心の中でそれは複数のプロジェクトであるべきだと言います。私は以前に両方の方法でそれを行っており、単一のプロジェクトソリューションを使用するとテストが簡単になることがわかりましたが、複数のプロジェクトを使用すると、再帰的な依存関係が発生する可能性があります。特に、クラスにテストを容易にするためのインターフェースがある場合、問題が発生する可能性があることがわかりました。

プロジェクトの規模によって異なります

これが私がよく使うガイドラインです

• ほんの一握りのページかそれ以下の小さなプロジェクトで、私はほとんど常に単一のプロジェクトを続けます。

• 小さなプロジェクトのデータアクセスレイヤーが大きいか複雑な場合は、それを独自のレイヤーに分離することがありますが、それ以外の場合は独自のフォルダーに配置されます。

• プロジェクトが大きい場合、ほとんどの場合、DAL用の個別のプロジェクトがあり、それ以上の分割は、アプリケーションの機能間の境界がどこにあるかに依存します。

• アプリケーションに複数の目的があり、それぞれに独自のビュー、ビューモデルなどがある場合、通常は各部分を独自の領域に分けます。各セクションが小さい場合は、フォルダで区切ります。各セクションが大きい場合は、プロジェクトごとに分けます。

• 私は、オブジェクト（の同じセット参照する必要がある複数のプロジェクトがある場合ViewModelBase、RelayCommandなど）を、私は共有インフラストラクチャオブジェクトのためのプロジェクトを作成します。

• 共有するカスタムスタイル/テンプレート/リソースが大量にある場合は、それらのためにプロジェクトを作成します。

補足として、私は最初の大きなWPFプロジェクトでミスを犯し、モデルを1つのプロジェクトに配置し、ビューを別のプロジェクトに配置し、ViewModelsを3番目のプロジェクトに配置することでそれらを分離しました。メンテナンスが悪夢になるので、今はそれが道ではないことを伝えることができます:)

レイヤーごとに1つのプロジェクトに加えて、レイヤーごとにテストプロジェクトを使用すると、最良の結果が得られます。ソリューションがすべてを網羅するソリューションでは、10以下のプロジェクトでは達成できないアプリケーションをいくつか見ました。

ネームスペースが本当に必要なプロジェクトを使用するという罠に陥らないでください。大量のプロジェクトを追加しても、オーバーヘッドが増えるだけで利益は得られません。

私見の分離はほとんど常により良いです。プロジェクトが100％自明でない限り、ほとんどの場合、データレイヤーを分離します。その理由は、データレイヤーが最も頻繁に渡される傾向があるためです。まれに、GUIを複数のデータレイヤーに接続して、正常に機能することを期待します。より一般的なシナリオは、単一のデータレイヤーがあり、それを複数のGUI（ASP.Net、WPF、Silverlightアプリなど）に分散させたい場合です。データレイヤープロジェクトをビルドし、そのDLLを次のGUIのリファレンスとして参照として追加できるのは素晴らしいことです。

私にとって、4 *はマジックナンバーです。各層に1つのプロジェクト、およびそれらの間の通信に必要なすべてのインターフェース/ DTOを定義する1つのプロジェクト。

* 7単体テストをカウントした場合

これらの異なるレイヤーで作業している場合、またはそれらと緊密に結合している場合は、常に単一のソリューションを使用してきました。F5キーを押して、必要に応じてすべてのプロジェクトを再構築してもらいたいです。それを行う「正しい」方法はないと思います。

その個人的な好み、最も重要なことは一貫していることです。個人的には、アプリケーションの各レイヤーに個別のプロジェクトがあるので、分離は明らかです。

プロジェクト数の増加は、単体テストを有効にし、依存関係グラフを単純化して、物事がそれほど複雑ではなく、アプリの一部に変更を加えると、アプリの無関係に見える部分の物事が壊れてしまうことに関係しています。

何らかの依存関係の逆転を行っているときに、すべての「コントラクト」、インターフェース、抽象クラス、データ転送オブジェクトを1つのアセンブリに配置することがうまくいきます。別のアセンブリでは、データベースと通信するものは何でも入れます。単体テストは独自のアセンブリを取得します。UIが根本的にテスト不可能な場合（ASP.NET winformsなど）、UIをテスト可能なコードとテスト不可能なコード（それぞれアセンブリ）に分割することには大きなメリットがあります。データベース、UI、またはこれまでに説明したこととは何の関係もないコードが表示され始めることがあります。これは、.NETフレームワークにあると思っていたコードです。そのコードをユーティリティアセンブリに配置するか、少なくともルートアセンブリ（おそらくインターフェイスを持つもの）に配置します。

すべてのアセンブリがすべてのアセンブリを参照する場合、またはほぼ参照する場合は、それらを1つのアセンブリにマージして戻す必要があります。データ層のコードをUIに配置し、UIをデータ層に配置することを防ぐ規律が欠けている場合は、すべてを1つのレイヤーにマージすることで、物事を簡素化します。

Visual Studioの一部のエディションでは、約15のアセンブリでパフォーマンスの問題が発生します。場合によっては、プロジェクトの種類によって異なります。ただし、プロジェクトファイルを戦略的にアンロードすると役立つ場合があります。

複数のプロジェクトを作成する唯一の正当な理由は、複数のアプリケーション間でクラスとファイルのセットを共有する必要がある場合です。

プロジェクトが1つのアプリケーションだけで使用されている場合、そもそもプロジェクトは作成されるべきではありません。代わりに名前空間を使用してください。ファイルを探すときの循環参照、dllオーバーヘッド、およびプロジェクトの混乱の問題を自分で解決してください。

その理由の詳細については、この記事を読んでください。http：//lostechies.com/chadmyers/2008/07/16/project-anti-pattern-many-projects-in-a-visual-studio- solution-file /

また、記事で述べているように、アプリケーション全体でコードを共有する以外に複数のプロジェクトを作成する正当な理由がある場合は、それが何かを教えてくれる人を歓迎します。