0

私は WinForms 製品の書き直しの非常に初期の段階にあり、新しいソリューション構造を実装するための「最善の」戦略を決定しようとしています。現在のソリューションには 50 以上のプロジェクトが含まれており、(ほとんどの場合) アプリケーションを実行するために必要なすべてのロジックが含まれています。いくつかのプロジェクトには、別の「フレームワーク」ソリューションに存在するプロジェクトへの依存関係がありますが、それも置き換え/変更されています。

前述したように、現在のソリューションは WinForms 製品を生成します。さらに、すべてが前から後ろまでしっかりと結合されています。さらに、WinForms 製品に加えて、またはそれに加えて、Web / モバイル ソリューションの提供を開始したいと考えています。望ましい変更のため、これをいくつかの個別のソリューションに分割することを検討しています。詳細は次のとおりです。

  • Product.Framework ソリューションは Product.Core になります - 共通のインターフェイス、列挙型、構造体、「ヘルパー」などを含むアセンブリの共有セット。
  • Product.Windows - MVC パターン。WinForms 製品を実行するために必要なすべてのビューとビジネス ロジックが含まれています。
  • Product.Web - MVC パターン。Web 製品を実行するために必要なすべてのビューとビジネス ロジックが含まれています。
  • Product.Services - ホスト可能な WCF サービス。基になる DAL を使用して Web/Win/Mobile が呼び出すパブリック サービス レイヤーが含まれます。

これは、健全性チェックを探している場所です。WinForms プロジェクトと Web プロジェクトの両方に DI/IoC を実装することを計画しています (WCF サービスへの挿入についてはあまり心配していません)。私の考えでは、すべての具体的なエンティティ (データベース テーブルの表現) とサービスのインターフェイスを Product.Core ソリューションに含めることは理にかなっています。Web および Winforms ソリューションで Product.Services を参照する必要があると思われる唯一の参照は、具象型をコンテナーに登録することです。

これは理にかなっていますか？私が見落としているギラギラしたものはありますか？フィードバックをお寄せいただきありがとうございます。

4

2 に答える 2

2

ソリューションについての私の考え方は、「プログラムを実行するために必要なものすべて」です。あなたの場合、WinForms アプリケーションが最後のステップです。目標は、そのプロジェクトから出力実行可能ファイルを実行できるようにすることです。したがって、ソリューションは、その実行可能ファイルをゼロからビルドするために必要なすべてのプロジェクトで構成される必要があります。あなたが望む最後のことは、新しい開発者がバージョン管理からソースコードをチェックアウトし、部族の知識を使用して、どのソリューションをどの順序で構築する必要があるか、そしてそれらをすべて結び付ける方法を理解する必要があることです.

Web アプリケーションなどの最終段階のアプリケーションをさらに追加する可能性があるとおっしゃいました。WinForms アプリケーションの依存関係が Web アプリケーションと似ていると仮定すると、Web アプリケーションを WinForms アプリケーションと同じソリューションに追加するだけでよいという意見があります。ただし、場合によっては、それぞれに異なるソリューションを用意し、各ソリューションで同様のプロジェクト セットを参照することが理にかなっている場合があります。

覚えておくべき重要なことの 1 つは、プロジェクトの依存関係が導入された場合、その新しい依存関係を持つようにすべてのソリューションを更新する必要があるということです。これが、私がほとんどのことに対して単一のソリューションを持つ傾向がある主な理由です。

Visual Studio では、ソリューション全体を視覚的に管理するのに役立つソリューション フォルダーを使用できることを忘れないでください。また、ビルド構成と依存関係ツリーを利用して、最終的なプロジェクトを 1 つだけビルドする必要がある場合に、ビルドですべてをコンパイルする必要がないようにすることもできます。最後に、Set Startup Project オプションを使用して、作業する最終出力を切り替えることができます。

どのプロジェクトも、簡単に複数のソリューションの一部になる可能性があることを覚えておいてください。さまざまな製品で使用されるコア セットのフレームワークがある場合は、各「製品」ソリューションにフレームワーク プロジェクトを含めることができます。フレームワークが主にそれを使用する同じチームによって作業されていない場合は、フレームワークを別のリポジトリに分割し、出力アセンブリのみを配布することを検討してください (他のリポジトリにコミットされ、他のソリューションで参照されます)。

一般的に、私の意見では、すべてに対して 1 つのソリューションを用意し、Visual Studio のさまざまな機能を利用することで、このような大規模で複雑なソリューションの管理はそれほど苦痛ではありません。私がアドバイスしたいことの 1 つは、あるソリューションのビルドを別のソリューションのビルド出力に依存させることです。これを行う場合は、2 つのプロジェクトを別々のリポジトリに配置し、必要に応じてビルド出力をコピーしてコミットする必要があります (基本的に、出力をサード パーティ ライブラリとして扱います)。

于 2013-10-19T23:35:41.677 に答える
0

ここに「最良の」答えはありません。あなたの質問からの観察は次のとおりです。すべての具体的なエンティティに対してインターフェイスが必要なのはなぜですか? これらは単なるデータ モデル クラスのようです。これらのクラスをモックするか、たとえばIEntityインターフェイスを実装するすべてのデータモデルクラスなどのクラスのカテゴリで動作できるジェネリックメソッド（またはクラス）を記述して、データによってジェネリックメソッド/クラスを制約できるようにする場合を除きますモデルタイプ。例：

public void MyGenericMethod<T>(T t) : where T:IEntity{ // do something}

あなたが行っているリファクタリング/再構築は、あなたが取り組んでいるビジネスに大きな影響を与え、現在行われている設計/アーキテクチャの決定は、ビジネスが進化するにつれて持続可能である必要があるようです. このプロセスには、ビジネスのニーズと性質を理解し、それに応じたゲーム プランを考えられるアーキテクトを関与させることを強くお勧めします。

于 2013-10-19T23:18:07.963 に答える