7

この質問はこの質問に似ていますが、その質問で説明されていない問題について質問しているため、重複していません。

Delphi 7 に、次のディレクトリ構造を持つクライアント サーバー プロジェクトがあります。

\MyApp
  \MyClientApp
  \MyServerApp
  \lib

MyClientApp フォルダーと MyServerApp フォルダーにそれぞれ 1 つずつ、2 つの実際の Delphi プロジェクト (.dpr) があります。

lib フォルダーには、クライアント アプリとサーバー アプリに共通のコードを持つ .pas ユニットがあります。私が疑問に思っているのは、これらの .pas ファイルをクライアント プロジェクトとサーバー プロジェクトに含める必要があるかどうかということです。または、これらのユニットを含む lib フォルダーにパッケージを作成する必要がありますか? または、.pas ファイルを lib フォルダーに置いたままにして、アプリ/パッケージに追加しないようにする必要がありますか?

各アプローチの長所と短所は何ですか? どの方法が「最良」ですか？lib フォルダーのユニットを複数のプロジェクトに含めることに問題はありますか?

現在、lib フォルダー内のユニットはアプリ/パッケージの一部ではありません。これの欠点の 1 つは、たとえば、Delphi でクライアント アプリを開いているときに、プロジェクト内のすべてのファイルで何かを検索したい場合、lib フォルダー内のユニットも検索されないことです。これらのユニットを開いて開いているすべてのファイルで検索を行うか、grep検索を使用することでこれを回避します（ただし、より良い解決策が望ましいです）。

また、lib フォルダー内のファイルに変更を加えたときに、別のパッケージを開いて再コンパイルする必要がないソリューションを大いに好むでしょう (これはプロジェクト グループを使用する必要がある場所ですか?)。

4

5 に答える 5

8

アプリケーション間でユニットを共有すると、一方のアプリケーションで互換性のない変更が行われ、もう一方のアプリケーションが破損するリスクが常にあります。一方、これらのユニットのコピーを作成することはさらに悪いので、それらを独自のサブディレクトリに移動するというアプローチは、少なくとも他のプログラムを考慮せずにそれらを変更することへの心理的な障壁を追加します。

それらをプロジェクトファイルに追加する場合：私は通常、IDEからプロジェクトに（拡張または参照のために）頻繁にアクセスするいくつかのユニットを追加し、コンパイラが検索パスを使用して選択できるように他のユニットを除外します。私はプロジェクトごとにそれを行います。つまり、いくつかのユニットがいくつかのプロジェクトの一部である可能性があります。

それらをパッケージに入れることは、実際にパッケージベースのアプリケーションを作成したい場合にのみ意味があります。そうでない場合は、なぜわざわざするのでしょうか。

プロジェクトとライブラリを整理する方法の詳細については、http： //www.dummzeuch.de/delphi/subversion/english.htmlを参照してください。

于 2009-02-13T07:38:40.803 に答える
5

プロジェクトでファイルを共有するのは嫌いです。あまりにも頻繁に、共有ファイルの 1 つを編集したくなり、他のプロジェクトの何かを壊したり、他のプロジェクトを再構築する必要があることを忘れたりします。

代わりに、共有ファイルが独自のライブラリ (パッケージ) に分割されている場合、それらを編集するには少し余分な障壁があります。それは良いことだと思います。プロジェクト固有のコードから共有コードに切り替えていることを簡単に思い出してください。プロジェクト グループを使用すると、すべてを 1 つの IDE インスタンスにまとめることができます。実行可能プロジェクトの前にライブラリ プロジェクトを配置します。「build all」コマンドは、最初のプロジェクトから順番にすべてをビルドします。

DCU ファイルを PAS ファイルとは別に保管してください。これは、「DCU 出力ディレクトリ」プロジェクト オプションを設定して、パッケージのユニットを別の場所に送信することで簡単に実行できます。次に、その宛先ディレクトリを他のプロジェクトの「検索パス」に配置します。DCU は見つかりますが、PAS ファイルは見つかりません。したがって、実際にはメンバーではないユニットを他のプロジェクトが誤って再コンパイルすることはありません。

個別のパッケージを用意すると、プロジェクト固有の条件定義の使用も妨げられます。プロジェクト間でユニットを共有している場合、これらはあらゆる種類の問題を引き起こします。代わりに、すべてのプロジェクト固有のオプションをそれぞれのプロジェクト内に保持する方法を見つけてください。共有ライブラリは、プロジェクト固有の変更を必要としません。ライブラリの使用者に応じてライブラリの動作を変える必要がある場合は、ライブラリのユーザーが設定してライブラリの動作を変更できるコールバック関数などの手法を採用します。

于 2009-02-13T00:19:06.553 に答える
4

共有コードをパッケージに追加するには、十分な理由が必要です。いくつかの共有ファイルしかない場合は、それらすべてを Shared というディレクトリに貼り付けます。これにより、ファイルがプロジェクト間で共有されていることが明らかになります。

また、優れたビルド ツールを使用して自動ビルドを実行すると、何かが壊れてもすぐにわかります。

.bpl ファイルはコンポーネントには問題ありませんが、大量の共有ファイルがない限り、このようなものはさらに複雑になります。

于 2009-02-13T11:02:19.847 に答える
3

私は通常、すべての共有ユニットを含むパッケージを作成し、ユニットのみを使用します。「ランタイム パッケージでビルド」を明示的にマークしない場合、パッケージ コンテンツ (すべての使用済み dcu) は、他のユニットとしてプロジェクトにリンクされます。

于 2009-02-13T00:04:26.103 に答える