Clever Geek Handbook

WildData：軽量データアクセスフレームワーク

こんにちは、％username％！ そこで、このリソースに関する記事を書くことにしました。 .NET、特にC＃で記述されたアプリケーションのデータにアクセスすることについてです。 すべての私の考え、そしてそれらが最終的に何をもたらしたのか、私はカットの下に着手しようとします。 ようこそ



この記事のDBMSとは、リレーショナルDBMSを意味します。 将来的には、提示されたライブラリ（フレームワーク）はEntity Frameworkの代替ではなく、それに依存せず、何の関係もないと言います。



それにもかかわらず、前述のフレームワークから休憩しましょう。 彼のアイデアの1つは、データアクセスの抽象化を導入する試み（そして非常に成功した試み）です。 つまり、特定のDBMSを回避します。



各DBMSには長所と短所があります。いくつかの機能を備えたものもあれば、いくつかの機能を備えたものもあります。 あることをうまくやる人もいれば、別のことをやる人もいます。 すべての長所と短所を比較検討した後、ある種のDBMSを選択して壮大な（またはそうでない）プロジェクトを実装し、... ADO.NETを使用してこれをすべて記述することにしました。



ADO.NETの長所：



  1. リクエストを完全に制御。
  2. 比較的シンプル：接続の作成、トランザクションの作成（オプション）、コマンドの作成、クエリテキストとパラメーターの追加、開始、データの読み取り（オプション）;
  3. ほとんどすべてのDBMSがサポートされています。
  4. DBMSとの密接な対話（たとえば、座標、JSONなどの「非標準」データ型のサポート）。


短所ADO.NET（プロジェクトの実装の前提条件）：



  1. モデルごとに、データベース内のレコードの読み取り、追加、変更を行うたびにコードを書き直す必要があります。つまり、オブジェクトをテーブル、ビューなどのレコードにマッピングする必要があります。 逆に、レコードをオブジェクトにマッピングします。
  2. Javaのような抽象化はありません（DbConnection / DbCommandおよびその他のクラスがありますが、特定のタイプ、たとえばSqlConnection / SqlCommandがよく使用されます）。
  3. レコードのパッケージの操作（追加、更新、追加または更新、削除）に対する普遍的なサポートはありません。


おそらく読者は、上記の欠点を取り除く方法を考えるとすでに推測しているでしょう。 プロジェクト全体を実装する鍵となるものについて話しましょう。



順番に始めましょう。



  1. このコードを一度書くために何ができますか？ まず、1つまたは複数のオブジェクトを読み取るためのバックボーンは、オブジェクトの種類または含まれるフィールドに関係なく、変更されないことに注意してください。 これは、単一のオブジェクトを読み取るための汎用関数が必要であることを意味します。 同じことが、レコードの追加と更新にも当てはまります。



    そのような関数はどのように書かれるべきですか？ 最初に思い浮かぶのは、リフレクションです。 言ってみよう。 しかし、Reflectionには1つの重大な欠点があります-それは遅いです。 1つのオブジェクトを読み取り/追加/変更/削除するときに速度が重要でない場合、オブジェクトが多数あるとオーバーヘッドが顕著になります。



    式とそれらをオンザフライでコンパイルする機能は、私たちの助けになります。 これは、関数の本体が生成、コンパイルされ、その関数へのリンクがデリゲートとして保存されるという考え方です。 これは、初期化中に1回だけ行う必要があります。



    関数は何と連携する必要がありますか？ 3つのエンティティ：



    • そのようなオブジェクト（モデル）;
    • データ読み取りオブジェクト（たとえば、SqlDataReader）;
    • パラメーターのコレクション（例：SqlParameterCollection）。


    これらの関数の生成ポイントを統一するために、IDbParameterCollectionWrapperおよびIReaderWrapperのラッパーインターフェイスが導入されています（以下のプロジェクトリポジトリへのリンクを参照）。 DBMSごとに、これらのインターフェイスを個別に実装する必要があります。 今後の展望：フレームワークは主に速度を目的としているため、場合によっては遅延（「遅延」）初期化が使用されます。 このフレームワークには、柔軟性を高めるためのいくつかの補助属性（計算フィールド、必須フィールドなど）も含まれています。



  2. フレームワークの共通部分全体は、別の一般的なプロジェクトで取り出されます。 ユーザーはほとんどのインターフェイスを見ることができます。 インターフェイスのみを使用することを強くお勧めします。



  3. レコードを使用したバッチ作業はまだ実装されていませんが、これはすでに「技術的な問題」です。


プロジェクトは既にテストできます（以下のリンクを参照）。 Linqのサポートがあります！ プロジェクトはアルファ版であるため、コードはまだ完全ではありません。



追加予定の内容：





参照：



» GitHubのWildDataプロジェクト。

» Nuget-package WildData。

» Nuget-package WildData（PostgreSQLの実装）。

» フレームワークを使用する非常に簡単な例。



判断しないよう厳しくお願いします。 これはHabrahabrに関する私の最初の記事です。 ご清聴ありがとうございました！



PSすべての質問については、PMとコメントでお願いします。


More articles:


All Articles