3

製品に取り組んでいる2つのチームがあります。1つのチームは、WCFサービスとして公開されているサーバー側のロジックに取り組んでおり、もう1つのチームは、フロントエンド（ASP.NET MVC Webサイト）の実装に取り​​組んでいます。これら2つのチーム間でサービスAPIを共有するための適切なソリューションは何ですか？APIとは、Webサービスインターフェイスと一連のDTOクラスを意味します。継続的インテグレーションにはgitとTeamCityを使用しています。サービスとフロントエンドは独立して開発および展開されます。

これに基づいて、私が見るオプションは次のとおりです。

  1. すべての「インターフェース」のものを別のプロジェクトに入れ、gitモジュールを介して共有します。クライアントとサーバーの両方がコードを共有します。
  2. すべての「インターフェイス」を別のプロジェクトに配置し、プライベートNuGetリポジトリに公開します。クライアントとサーバーの両方が、唯一の共通のアセンブリを参照します。
  3. クライアントとサーバーの両方を単一のVSソリューションに配置し、文字通りアセンブリを共有します。

オプション3は、最も簡単なアプローチのように感じられ、実装と理解が容易ですが、より大きなソリューションを取得するというアイデア全体にはあまり興奮していません。オプション1と2はほとんど同じように感じますが、私はオプション2の方が好きです。

ここでのより良いアプローチは何だと思いますか？他の解決策はありますか？

4

3 に答える 3

6

オプション4-クライアントとサーバーは別々のソリューションにありますが、両方のソリューションに同じWCFコントラクトプロジェクト（[DataContract]と[ServiceContract]定義のみを含む）が含まれており、アセンブリ参照ではなくプロジェクト参照で参照しています。面白そうに聞こえるかもしれませんが、問題なく動作します。

両方のソリューションは別々にビルドでき、どちらも同じDLLを取得します。これは、どちらの順序でビルドされても、2番目のビルドはDLLが既に最新であるため、再コンパイルしないためです。

私が見ているように、これの主な利点は、誰かが契約プロジェクトにソースコードを変更すると、何も「更新」することなく、クライアントとサーバーの両方のコードですぐに変更を利用できることです。これにより、「私はその変更を行いました」、「いいえ、あなたはしませんでした」、「はい、私は行いました」、「まあ、私はそれを見ることができません」などの議論を切り取ります。

于 2012-12-07T08:25:38.790 に答える
2

共通のコードは別のソリューションに保存します。.dllを生成し、それらに依存する他の複数のプロジェクトへの単純なアセンブリ参照として追加されます。

すべてのビルドはnantファイルで定義されており、ビルドを適切な順序で実行する.batファイルがいくつかあります。

VSからプロジェクトをビルドしたいだけの場合、依存する.dllはおそらくすでにビルドされています。100％になりたい場合は、すべてが最新の変更でビルドされています。これらのbatスクリプトを実行すると、nantビルドがトリガーされ、すべてが再構築されます。

于 2012-12-07T09:01:39.213 に答える
1

私のプロジェクトでは、オプション1の共有コードで説明したのと同様の方法を使用しました

于 2012-12-07T08:14:42.023 に答える