Delphi Data -Awareコンポーネントの使用 - 長所と短所[閉じた

StackOverflow https://stackoverflow.com/questions/4722563

質問

プロジェクトでデータ認識コンポーネントを使用することについてのあなたの意見を知りたいです。 DelphiとData-Awareコンポーネント（Delphiの標準的なスイートまたはサードパーティから）を使用して、アプリケーションを開発する「強度」と「弱い」ポイント（Win32およびWeb）はどれですか？

Firebirdを使用して、私はIbobjectsでよく働いていました。これは成熟したコンポーネントであり、非常にうまく機能しています。

しかし、他にも多くのRDBM（MySQL、MSSQL、DB2、Oracle、SQLite、Nexus、Paradox、Interbase、Firebirdなど）もあります。多くのデータ認識コンポーネントを使用した大きなプロジェクトを開発した場合は、データベースタイプとデータ認識コンポーネントスイート名で答えてください。

DB2（AS400）にも興味があります。成功してどのコンポーネントを使用しましたか、それとも実際に作業するのに苦労していますか？

役に立ちましたか？

解決

データ認識コンポーネントを使用すると、ビジネスロジックとUIロジックを明確に区別することなくアプリケーションが発生することがわかりました。

これは小さなプロジェクトでは問題ありませんが、大きくなるにつれてコードがますます保守性が低下します。

イベントコードのさまざまなビット（およびその相互作用）は、理解するための本当の悪夢になる可能性があります！

そのような場合、常にデータ認識コンポーネントを捨て、（手コーディングされた）MVC設計に切り替えました。

これには、メンテナブルで拡張可能でデバッグ可能なプロジェクトでは、多くの前払いコーディングの取り組みが必要ですが、結果（IMHO）が必要です。

他のヒント

DELPHIアプリケーションのデータ認識スタイルと非データ認識スタイルの両方を試してみたので、最近のデータ認識コンポーネントキャンプに戻りました。コードを正しく階層化するには、少しの作業と規律が必要ですが、データ認識以外のコントロールを使用してすべてを手作業で行うよりも速いです。

データ認識コンポーネントの使用に関する私のヒントのいくつかは、

  • Fishfactを大規模に書き換えないでください。あなたのデザインにいくつかの考えを入れてください。

  • tdatamoduleを使用しないでください たくさんの Tdatamodulesそれぞれがアプリケーションデータのわずかな側面を担当します。

  • Tdatasetsはtdatamodulesに属し、Tdatasourcesはtformsに属します（マスター/ディテール関係に使用されない限り）。

  • DataSNap TClientDatasetなどのメモリ内データセットを使用します。

  • ClientDatasetsは、データベーステーブルを正確に反映する必要はありません。 DataSNAPを使用すると、メモリ内のデータ構造をマッサージできるため、特定の目的に合わせて調整されたデータセットを作成できます。具体的には、ようなことができます

    • 2つ以上のテーブルを1つの編集可能なデータセットに結合する

    • 非正規化マスターディテールテーブル構造により、UIコードを時々簡素化できます。

    • メモリのみのフィールドを作成します（計算されたフィールドと同様ですが、それらにも書き込むことができます）

  • TclientDatasetネストされたテーブルは便利ですが、マスターディテール関係を表現する唯一の方法ではありません。 2つの独立したTclientDatasetsがTDataSourceを介して参加した古い方法でそれを行う方が良い場合があります。

ORMソリューションをご覧ください。

マルチ層アーキテクチャを使用した素晴らしいアプローチです。見る Delphi win32のorm

データ認識コントロールは優れていますが、ビジネスコードを別のレイヤーに入手する必要があります。

それは難しくありませんが、それがどのようにできるかを知っておく必要があります。

1つのアプローチは、データモジュール（または他の非視覚コンテナ）にデータセットコンポーネントを置くことです。

もう1つの便利なトリックは、TClientDatasetを使用してUIエントリを実行し、UIとビジネスレイヤーの間の中間バッファーとして使用することです。その後、ビジネスレイヤーは、データレイヤーに固有のTDATASETコンポーネントを使用します。

- ジェロエン

Delphi Data Awareコンポーネントは、使用しているバックエンドデータベースエンジンに依存していないため、FireBirdまたはMS SQL Server、Oracleなどを使用すると、データ認識コンポーネントには関係ありません。彼らは彼らに割り当てられたDataSourceコンポーネントのみを知っており、それを介してすべてのDB関連のことを行います。

私にとっては、データ認識コンポーネントで何かを良い方法で行うことができれば、それらを使用します。これらは通常、短時間で行うべき小さなプロジェクトです。より大きなプロジェクトでは、データ認識コンポーネントを完全に除外するか、データプレゼンテーションに使用され、ユーザー入力を受け取らない形式で使用する場合があります。ユーザー入力の受信に関しては、非DATA認識コンポーネントを使用する可能性があります。なぜなら、それらを制御して入力を検証する柔軟性が高いためです。もちろん、このようなシナリオでもデータウェアコンポーネントが役立つ場合があります。 onbeforepostのようなデータセットイベントでユーザー入力を検証することができます。また、マルチ層設計を使用していて、クライアントアプリがデータプレゼンターレイヤーを表している場合、入力検証は中層で実行されるため、クライアントアプリのデータ認識コンポーネントを使用して入力を受信し、検証とさらなる処理のための中間層。

データ認識コンポーネントは、特にデータに基づいたレポートまたはグリッドを設計する場合、RADおよびプロトタイピングの観点から使用できます。つまり、設計時にいじくり回すことができます。だから私はそれらをそのように使用します。しかし、それを配送コードに変換する時が来たら、私はほとんど常に接続を切断し、クエリからSQLを削除し、コードですべてを実行します。特にバージョン制御を備えたマルチ開発環境では、より予測可能で保守可能です。 SQLがどこかにフォームに埋め込まれている場合、SQLが実際にどこに存在するかを把握しようとするのは大きな苦痛です。そして、2つの場所にSQLを持っていることは特に悪いことです。そして、どちらが有効であるかを把握する必要があります。

使用できます unidac Firebird（私が使用している）を含む多くのデータベースサーバーをサポートし、非常に優れた機能を備えています。

と相まって Remobject SDK n層アーキテクチャとデータベースの抽象化の素晴らしい組み合わせがあります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top