DelphiのORMを書く

みなさんこんにちは！

今日は、 DoctrineおよびJava EEプラクティスの影響下でRTTIを使用してDelphiのORMを作成した私の経験について説明します。

なんで？

最近、Delphi7の古いプロジェクトが私の権限の下に落ちました。これは、Interbase 2009の下でデータベースを積極的に使用しています。このプロジェクトのコードは楽しいものでした。 データの取得、更新、新しいエントリの作成、削除-これらはすべて、アプリケーションロジックの多くの行を占有し、コードを理解することを非常に困難にしました（救いは、24時間私の愚かな質問に答えた良心的な開発者にあります）。 プロジェクトは、古いトラブルを取り除き、新しいモジュールを追加するために私に引き渡されました。そのタスクは、新しいデータベーステーブルをカバーすることです。



私はMVCアプローチが好きで、モデルコードとロジックコードを共有したかったです。 そして、純粋さのために-新しいテーブルのすべてのget / setメソッドを書き直したくはありませんでした。 数年前、ORMの概念を知るようになり、それが気に入りました。 私はこの原則が好きで、仕事にそれを適用できてうれしかったです。

その瞬間、私はDelphi7で少なくともDoctrineに似たもの、またはテーブルのEntity / Facadeクラスのジェネレーターを検索するために急いで行きました...どちらでもありません。 しかし、検索結果にはいくつかの既成のソリューションがありました。 たとえば、 DORM 。 一般的に、素晴らしいことであり、実際、必要なものです！



しかし、それがあなたに起こるかどうかはわかりません。非常に限られた機能が必要なため、既製のソリューションを拒否しました。DORMまたはtiOPFのコンテンツ全体をドラッグする必要はありません。 私が望むものを実現し、すべての欠点を理解して、私はこの滑りやすい斜面を取り、到達したようです...

反射

ORMに少なくともある程度の類似性がないことは、首の痛みです。 私はこれについて話しています-Javaでは、既成のデータベースを使用して、作成されたエンティティを操作するための一連のエンティティクラスとファサードを作成できます。 これらのクラスの目的は、特定のデータベースと対話するための既製のツールを開発者に提供し、クエリテキストからアプリケーションロジックのメインコードを消去し、実行結果を解析することです。 同じことが、すべての一般的なPHPフレームワークで、Qtで（メモリがうまく機能していれば）何らかの形で使用されています。



オブジェクトマッピング用に高品質のライブラリを実装し、IDEに含めることの難しさは何ですか？ タスクは、データベースに接続し、ユーザーにアプリケーションで必要なテーブルを尋ね、テーブルのフィールドとテーブル間の関係を（外部キーによって）読み、すべての関係が正しく理解されたかどうかを明確にし、収集されたデータからクラスを生成します。 生成とは、つまり、何らかのテーブルからの1つのレコードのリポジトリをタスクとするエンティティクラスの作成です。 テーブルの名前がわかれば、そのすべてのフィールド、フィールドタイプを確認し、この情報から必要な情報を宣言し、公開されたセクションを生成し、必要なセッターとゲッターを追加します...一般に、タスクは時間がかかりますが、実現可能です。

エンティティークラスを生成した後、IDEはファサードクラス（または、それらをアダプターと呼ぶ）の生成を開始できます。 アダプターは、プログラマーとデータベースの間のレイヤーであり、その主なタスクは、特定のキーに対応するエンティティを受信し、そのキーの変更を保存し、削除できるようにすることです。 一般に、アダプタの本質は、データベースを操作するための開発者メソッドを提示することであり、その結果は、それらに対応するエンティティのオブジェクトの形式で提示されます。



Delphiでの開発のこの側面は好きではありませんでした。 彼との私の経験はすでに比較的大きく、この困難な問題には多くの利点がありますが、新しい言語や環境について学べば学ぶほど、Delphiは適切ではあるが、困難で困難なときに必要なレベルに達しないツールであると感じています。私はそれほど多くの時間を費やす必要はありません。



エンティティの生成をヒーローの肩に移す準備ができています。 おそらく、誰かがこれをCastaliaとしてIDE自体に埋め込むことさえできるでしょう。 しかし、サンプリング、更新、削除のメソッドをエンティティごとに個別に記述する理由はありません。 したくない findAllメソッドを呼び出して目的のテーブルからすべてのレコードを取得するエンティティの名前を渡すクラスが必要です。 または、find（5）を書き込み、数字キー5でレコードを取得します。

プロセス

TUAdapterクラスを開発しています。

結果としてアダプターができること：

1. クラス名でオブジェクトを作成します。
2. クラスフィールドを受信できる
3. フィールド名でオブジェクトフィールドの値を取得できる
4. すべてのデータをサンプリングできる
5. キーでエンティティを取得できます
6. データベース内のエンティティデータを更新できる
7. データベースからエンティティを削除できる
8. データベースから新しいエンティティを追加できます。

私の制限：

1. PDOなし-1つのデータベースの開発-Interbase
2. Delphi7には、まだ古いバージョンのRTTIがあります。 （Rad 2010 RTTIは大幅に改善されました）。 公開されたフィールドのみを取得できます
3. 関係および関係によるエンティティの取得（内部的な理由による）は実現されません。

0.抽象クラスTUEntity-すべてのエンティティの親

TPersistentを継承する必要があります。継承しないと、RTTIを完全に適用できません。 その中で、エンティティのインターフェースも調整します。 アダプタは、作業中にエンティティに対応するテーブルの名前を要求し、検索が行われるキーフィールドの名前、このフィールドの値、およびエンティティの文字列表現のメソッド（たとえば、ログ）を提供します。

1.名前でオブジェクトを作成する

エンティティはTPersistentクラスから継承されることは既に示しましたが、エンティティを名前で作成するには、必要なすべてのエンティティのクラスを登録するように注意する必要があります。 これは、最初の行のTUAdapter.Create（）コンストラクターで行います。



作成方法自体は次のようになります。 エンティティ名に引数を渡さないのはなぜですか？ タスクのコンテキストにあるため、作業の過程でオブジェクトが追加で作成され、エンティティの名前は常に同じままであるため、これを行う意味がわかりません。アダプタの作成時に送信されます

2.クラスフィールドの取得

これは、Delphiの開発者からよく聞かれる質問だと思います。 主な「機能」は、必要なすべてのフィールドを取得することはできず、公開されたセクションのプロパティフィールドのみを取得することです。 実際、これは非常に優れています。タスクでプロパティを使用すると非常に便利だからです。

3.フィールド名によるオブジェクトフィールドの値の取得

これを行うには、GetPropValueメソッドを使用できます。 PreferStringsパラメーターについて説明します-tkEnumerationおよびtkSetタイプのフィールドの結果がどのように返されるかに影響します。 Trueの場合、enumはtkEnumerationから返され、SetPropはtkSetから返されます。

 (Instance: TObject; const PropName: string; PreferStrings: Boolean): Variant;.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

4,5,6 ...データベースの操作

私は、コード全体を引用するのは悪い形だと思います（そして記事の最後の位置）。 そして、ここでは、すべてのデータを選択するための要求の形成の例について、一部のみを示します。

データサンプリングの場合、読み取りトランザクションが生成され、要求が作成されます。 クエリとトランザクションをバインドし、それらを実行してTIbSQLのすべての値を取得します。 TIbSQL.EoFとTIbSQLを使用して、次にすべてのレコードを反復処理できます。新しいエンティティの作成、配列への配置、フィールドへの入力を交互に行います。



他の問題では、いくつかの困難に言及することを忘れないでしょう。 まず、エンコーディング。 データベースがWIN1251エンコーディングで作成され、照合がインストールされたwin1251を使用しており、Delphiからこのデータベースを操作する必要がある場合、キリル文字を含むエントリを取得して追加することはできません。 この場合、リンクIBase.ru Rus FAQの情報をお読みください 。 その後、彼らはあなたに教え、すべての落とし穴に指を突くでしょう。



私が読んだものの私の集計は、次の一連のアクションのように見えます。

1. Borland Shared \ BDE \フォルダからbdeAdmin.exeを実行します
2. [構成]-> [システム]-> [初期化]でデフォルトのドライバーParadoxを選択し、Langdriver = Pdox Ansi Cyrrilic
3. [構成]-> [ドライバー]-> [ネイティブ]で、Langdriver = Pdox Ansi Cyrrilicをドライバーに追加します。MicrosfotParadoxドライバー、InterbaseへのData Direct ODBC、Microsoft dBaseドライバー。
4. [適用]をクリックして、オブジェクトのメインメニューの変更された要素に残り、変更を保存します。

この一連のアクションは、更新または挿入のリクエストに問題がないようにするのに役立ちます。 （およびSelectでは、キリル文字に問題はありません）。

場合によっては、代わりに次のことも役立ちます。

UPDATE tablename SET field = '';





書く：

UPDATE tablename SET field = _win1251'';





ただし、TIbSQLは_win1251関数に精通していないため、パラメーター付きのクエリを使用する場合、これは機能しません。

たとえば、このようなコードは機能せず、例外をスローします。

 IbSQL.SQL.Add("UPDATE tablename SET field = _win1251 :field"); IbSQL.Prepare(); // <- Exception IbSQL.Params.byName('field').asString := '';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、上記の4つのステップを完了した後、_win1251を使用する必要はなく、リクエストを自由に行うことができます。 私は気づかずに、難しい道を選び、独立してリクエストを作成することにしました。 パラメータ化が送信されたパラメータのフィルタリングの負担の一部を引き受けることを考慮しませんでした。 どういう意味か分かりませんか？



フィールドのテキスト値に引用符または改行があると、問題が発生しました。 そして、これらの文字を有効な文字に置き換えるメソッドを作成する必要がありました。

結果

一般に、Enitityクラスの要件を開発しました。

1. プライベートフィールドを記述する
2. 公開されたセクションのプロパティとして、テーブルの列に対応するフィールドを記述します
3. プロパティの名前は、対応する列の名前と一致する必要があります
4. 必要に応じて、フィールドのGet / Setメソッドを実装します（ブール値、TDateTime、Blobフィールドの場合）

次のデータベースがあるとしましょう



2つのEntityクラスTUserとTPostを作成します。



そして、アダプターと一緒にコードで使用すると、次のようになります。

 var Adapter : TUAdapter; users: TUsersArray; i: integer; begin Adapter := TUAdapter.Create(db, 'User'); try users:= TUsersArray(Adapter.FindAll()); for i:=0 to Length(users) -1 do begin Grid.Cells[0, i+1] := VarToStr(users[i].id); Grid.Cells[1, i+1] := VarToStr(users[i].name); Grid.Cells[2, i+1] := VarToStr(users[i].email); Grid.Cells[3, i+1] := VarToStr(users[i].password); SetRateStars(i, VarToStr(users[i].rate)); Grid.Cells[5, i+1] := VarToStr(users[i].last_login); end; finally Adapter.Destroy; end; end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結論

RTTIを使用してコードの速度に焦点を当てたいと思います。 RTTIメソッドを頻繁に使用するとアプリケーションの速度が低下することが経験上示唆されていますが、実際には、開発されたクラスの速度で十分です。 目標は達成されたため、機能がほとんどないORMがありますが、それに割り当てられたタスクは正直に解決しています。



BitBucketのプロジェクト。



PS

デルファイに対する否定的な考えを引き起こす傾向がある読者は、このことを全員に伝える必要はないことを思い出させてください。 皆さん、コントロールしてください。

申し訳ありませんが、実際には例外をスローするのではなく、エラー時にMessageBoxを呼び出しています。 しかし、私は自分自身を修正します、私は約束します。



UPD：

コード内にMessageBoxはもうありません。