異なるプロジェクト間でクラスまたはインターフェースを共有する


17

私はSOまたはここでいくつかの答えを探していましたが、結果なしで、あなたに尋ねる理由です。

アプリのサーバー部分とクライアント部分など、2つの異なるプロジェクトがあると仮定しましょう。私は自分のパートを開発していますが、友人は2番目のパートを作成しています。しかし、私たちの両方のようないくつかの共通のインターフェイスを使用する必要があるUserか、AccountInfoまたはChangableAccount順番に互換性を確保するために何でも...。たとえば、クライアントがユーザーデータをサーバーに送信する場合、サーバーは同じクラスで動作する必要があります。インターフェイスなどでも同じです。さらに、共通のインターフェイスに変更がある場合は、両方のプロジェクトでコードを新しい状況に合わせて調整する必要があります。

私が今見ることができる唯一の解決策は、すべての一般的なものが定義されている1つの余分なプロジェクトを作成することです。私たちと私の友人は、このプロジェクトをメインプロジェクト(クライアントまたはサーバー)への依存関係として追加する必要があります。共有プロジェクトは何らかのバージョン管理システムで管理できるため、常に最新の状態になります。

他にどのような解決策を提案しますか?このような問題はプロのアプリでどのように解決されますか?


1
何かを共有するかどうかにかかわらず、バージョン管理を行う必要があります。クライアントプロジェクトとサーバープロジェクトにバージョン管理を使用していないと言っていますか?その場合は、すぐに修正してください。
セバスチャンレッド14年

回答:


15

すべての共通事項が定義されている1つの追加プロジェクトを作成します

これは、再利用可能なパーツを共有するためのまさに最初のステップであり、簡単な部分です。より困難な部分は、共有ライブラリを使用している2つのプロジェクトが独立したリリースサイクルを持つかどうかを決定することです。「プロジェクトA」が共有ライブラリのバージョン1.0を使用し、プロジェクトBが同時にバージョン2.0 。

後者を可能にしたい場合は、ライブラリの厳密なバージョン管理スキームとリリース管理(および@RoryHunterによって提案されるようなライブラリファイル名の一部としてのバージョン番号)が必要です。この状況では、libの下位互換性にも注意する必要があります。ライブラリは個別の製品として管理し、ユニットテストを追加して、本番環境のさまざまなバージョンが適切であることを確認する必要があります。Mavenのようなツールも理にかなっています。

ただし、そのような状況を防ぎたい場合は、「プロジェクトA」、「プロジェクトB」、およびlibを共通のプロジェクトとして管理し、開発、ビルド、およびリリースのプロセスを組み合わせて行う必要があります。これにより、共有ライブラリの共通インターフェースを最初のシナリオよりもはるかに頻繁に変更できます。また、ライブラリファイル名にMavenやバージョン番号のようなものは必要ありません。ただし、AとBを独立して開発することはできません。


13

あなたのソリューションは正しいものです。共有コードを、独自のJARファイルをビルドする別のプロジェクトに入れ、両方のプロジェクトで使用します。JARファイルをビルドするとき、名前にバージョンを含めることができます(例:Debianスタイル)。

libmyproject-shared-1.0.jar

バージョン管理のトラブルを防ぐことはできませんが、役立つはずです。私はMavenを使用したことはありませんが、この状況でMavenが役立つことを理解しています。


2

すべての共通事項が定義されている1つの追加プロジェクトを作成します

それがまさに.Netがあなたに期待している方法です。

これらのオブジェクトを3番目のアセンブリに抽象化し、両方のプロジェクトからこれを参照します。Interfacesとしてそうすることをお勧めします。

シリアル化に注意してください:

  • 私は2つのプログラム間の直接シリアライズ/ deserialiseオブジェクトことができる唯一の方法は、(確かにこれはだっしばらく Framework 2.0を使用して前)クライアントとサーバーの両方のマシン上のグローバルアセンブリキャッシュにアセンブリ「共有」をインストールすることでした。アセンブリが各プロジェクトに対して「ローカル」である場合、フレームワークはそれらを個別のタイプとみなし、一方を他方にシリアル化することを拒否しました。
  • そして、インターフェースとしてタイプされたオブジェクトを直列化することは、ちょっとした「挑戦」です。元の非インターフェイスタイプは、シリアル化の「パイプ」を介して「作成」されたように見えなかったため、受信者は着信ストリームからどのような具体的なタイプを「構築」するかを知りませんでした。

1

他の人が示唆しているように、あなたの思考プロセスは正確です。専門的には、ほとんどはMavenGradleなどを使用して、これらの依存関係を効率的に管理します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.