プロジェクトでのデータベース対応コンポーネントの使用についてのご意見をお聞かせください。Delphiおよびデータベース対応コンポーネント（Delphiの標準スイートまたはサードパーティ製）を使用して、アプリケーション（win32およびweb）を開発する際の「長所」と「短所」はどれですか。
FireBirdを使用して、成熟したコンポーネントのスイートであり、非常にうまく機能するIBObjectsを使用して多くの作業を行いました。
しかし、他にも多くのRDBMS（MySQL、MSSQL、DB2、Oracle、SQLite、Nexus、Paradox、Interbase、FireBirdなど）があります。多くのデータ対応コンポーネントを使用した大規模なプロジェクトを開発した場合は、データベースタイプとデータベース対応コンポーネントスイート名で回答してください。
DB2（AS400）にも興味があります。どのコンポーネントを使用して成功しましたか、またはどのコンポーネントを使用するのが本当に面倒ですか？
データベース対応コンポーネントを使用すると、ビジネス ロジックと UI ロジックが明確に区別されないアプリケーションになることがわかりました。
これは小さなプロジェクトでは問題ありませんが、プロジェクトが大きくなるにつれて、コードの保守性が低下します。
さまざまなイベント コード (およびそれらの相互作用) をすべて理解するのは非常に困難です。
そのような場合、私は常にデータ認識コンポーネントを捨て、(ハンドコーディングされた) MVC 設計に切り替えました。
これには多くの先行コーディング作業が必要ですが、その結果 (IMHO) は保守可能、拡張可能、およびデバッグ可能なプロジェクトになります。
Delphi アプリケーションのデータ対応スタイルと非データ対応スタイルの両方を試してみた結果、最近はデータ対応コンポーネント キャンプに戻ってきました。コードを正しく階層化するには、多少の作業と規律が必要ですが、データベースを認識しないコントロールを使用して手動ですべてを行うよりも高速です。
データベース対応コンポーネントの使用に関する私のヒントのいくつかは次のとおりです。
FishFact を大規模に書き直さないでください。あなたのデザインにいくつかの考えを入れてください。
TDataModule を使用しないでください。多くのTDataModule を使用して、それぞれがアプリケーション データのほんの一部を担当します。
TDatasets は TDataModules に属し、TDataSources は TForms に属します (マスター/詳細関係に使用されない限り)。
DataSnap TClientDataSet などのメモリ内データセットを使用します。
ClientDataSet は、データベース テーブルを正確にミラーリングする必要はありません。DataSnap を使用すると、メモリ内でデータ構造を操作できるため、特定の目的に合わせて調整されたデータセットを作成できます。具体的には、次のようなことができます
2 つ以上のテーブルを 1 つの編集可能なデータセットに結合する
マスター ディテール テーブル構造を非正規化すると、UI コードが簡素化される場合があります。
メモリ内専用フィールドを作成します (計算フィールドと同様ですが、それらにも書き込むことができます)
TClientDataSet のネストされたテーブルは便利ですが、マスターと詳細の関係を表現する唯一の方法ではありません。TDataSource を介して結合された 2 つの独立した TClientDataSet を使用して、古い方法で行う方がよい場合があります。
ORM ソリューションをご覧ください。
これは、多層アーキテクチャを使用した優れたアプローチです。DELPHI win32 の ORM を参照してください。
データ認識コントロールは優れていますが、ビジネス コードを別のレイヤーで取得する必要があります。
それは難しいことではありませんが、それを行う方法を知っておく必要があります。
1 つの方法は、DataSet コンポーネントを DataModule (またはその他の非ビジュアル コンテナー) に配置することです。
もう 1 つの便利な方法は、TClientDataSet を使用して UI エントリを実行し、それを UI とビジネス レイヤ間の中間バッファとして使用することです。次に、ビジネス レイヤは、データ レイヤに固有の TDataSet コンポーネントを使用します。
--jeroen
データ対応コンポーネントは、特にデータに基づくレポートやグリッドを設計している場合に、RAD およびプロトタイピングの観点から役立ちます。つまり、設計時にいじることができます。だから私はそれらをそのように使います。しかし、出荷コードに変換する段階になると、ほとんどの場合、接続を切断し、クエリから SQL を削除して、コードですべてを実行します。特にバージョン管理のあるマルチ開発者環境では、その方がはるかに予測可能で保守しやすいです。SQL がフォームのどこかに埋め込まれている場合、SQL が実際に存在する場所を把握しようとするのは非常に困難です。また、SQL が 2 つの場所にあり、どちらが有効であるかを把握しなければならないのは特に悪いことです。
Delphi データベース対応コンポーネントは、使用しているバックエンド データベース エンジンに依存しないため、Firebird、MS SQL Server、Oracle などの使用は、データベース対応コンポーネントにとって重要ではありません。それらは、割り当てられたデータソース コンポーネントのみを認識し、それを介してすべての DB 関連の処理を行います。
私にとっては、データベース対応のコンポーネントで何か良いことができるなら、それを使用します。これらは通常、短時間で実行する必要がある小規模なプロジェクトです。大規模なプロジェクトでは、データ対応コンポーネントを完全に除外するか、単にデータ表示に使用され、ユーザー入力を受け取らないフォームでそれらを使用することがあります。ユーザー入力の受信に関しては、非データベース対応コンポーネントを使用することがあります。これは、それらを制御して入力を検証する柔軟性が高いためです。もちろん、データウェア コンポーネントは、このようなシナリオでも役立ちます。OnBeforePost などのデータセット イベントでユーザー入力を引き続き検証できます。また、多層設計を使用していて、クライアント アプリがデータ プレゼンター レイヤーを表している場合、入力の検証は中間層で行われるため、クライアント アプリのデータベース対応コンポーネントを使用して入力を受け取ることができます。