異なるプロジェクト間でクラスまたはインターフェースを共有する
SOまたはここでいくつかの答えを探していましたが、結果がなかったので、あなたに尋ねます。
たとえば、アプリのサーバー部分とクライアント部分の2つの異なるプロジェクトがあるとします。私は自分のパーツを開発していますが、私の友人は2つ目のパーツを作成しています。ただし、互換性を確保するために、どちらもUserまたはAccountInfoまたはChangableAccount...などの一般的なインターフェイスを使用する必要があります。たとえば、クライアントがユーザーデータをサーバーに送信する場合、サーバーは同じクラスで動作する必要があります。インターフェースなども同様です。さらに、共通のインターフェースに変更がある場合、両方のプロジェクトでコードを新しい状況に合わせて調整する必要があります。
今私が見ることができる唯一の解決策は、すべての一般的なものが定義されている1つの追加プロジェクトを作成することです。私と私の友人は、このプロジェクトを依存関係としてメインプロジェクト（クライアントまたはサーバー）に追加する必要があります。共有プロジェクトは、いくつかのバージョン管理システムで管理できるため、常に最新の状態になっています。
他にどのような解決策を提案しますか？プロのアプリでそのような問題はどのように解決されますか？
すべての一般的なものが定義されている1つの追加プロジェクトを作成する
これは、再利用可能なパーツを共有するための最初のステップであり、簡単なパーツです。より難しい部分は、共有ライブラリを使用している2つのプロジェクトに独立したリリースサイクルがあるかどうかを判断することであり、プロジェクトBが使用している間に「プロジェクトA」が共有ライブラリのバージョン1.0を使用する可能性がある場合バージョン2.0 同時に。
後者を可能にしたい場合は、ライブラリの厳密なバージョン管理スキームとリリース管理（および@RoryHunterによって提案されたようなライブラリファイル名の一部としてのバージョン番号）が必要です。この状況では、libの下位互換性にも注意する必要があります。ライブラリは個別の製品として管理し、ユニットテストを追加して本番環境のさまざまなバージョンが適切であることを確認する必要があります。また、Mavenのようなツールも有効です。
ただし、preventの状況が必要な場合は、「プロジェクトA」、「プロジェクトB」、およびlibを、開発、ビルド、リリースのプロセスを組み合わせた共通のプロジェクトとして管理する必要があります。これにより、共有ライブラリの共通インターフェースを、最初のシナリオよりもはるかに頻繁に変更できます。また、ライブラリファイル名にMavenやバージョン番号のようなものは必要ありません。ただし、AとBを独立して開発することはできなくなります。
あなたの解決策は正しいものです。共有コードを独自のJARファイルを構築する別のプロジェクトに配置し、両方のプロジェクトで使用します。 JARファイルをビルドするとき、名前にバージョンを含めることができます。 Debianスタイル。
libmyproject-shared-1.0.jar
バージョン管理の問題を防ぐことはできませんが、役立つはずです。私はMavenを使用したことがありませんが、この状況で役立つことを理解しています。
すべての一般的なものが定義されている1つの追加プロジェクトを作成する
これは、.Netが期待する方法とまったく同じです。
これらのオブジェクトを3番目のアセンブリに抽象化し、両方のプロジェクトからこれを参照します。よりクリーンなインターフェイスとして行うことをお勧めしますが、...
シリアル化に注意してください：
- 2つのプログラム間でオブジェクトを直接シリアライズ/デシリアライズできる唯一の方法（確かに、これはwhile以前はFramework 2.0を使用していた）は、クライアントとサーバーの両方で「共有」アセンブリをグローバルアセンブリキャッシュにインストールすることでしたマシン。アセンブリが各プロジェクトに対して「ローカル」である場合、フレームワークはそれらを個別のタイプと見なし、一方を他方にシリアル化することを拒否しました。
- そして、インターフェイスとして型付けされたオブジェクトを[デ]シリアライズすることは、少し「挑戦」です。元の非インターフェイスタイプは、シリアライゼーションの「パイプ」を介して「作成」するようには見えなかったため、受信側ストリームは、受信ストリームから「構築」する具体的なタイプを知りませんでした。