このリポジトリにデータ アクセス トピックの例を作成しました。エンティティフレームワーク、データファースト、コードファースト、Orm、データベース作成などのトピックに関する例とプロジェクトがあります。
これは、リレーショナル データベースとオブジェクト指向プログラミング (OOP) の間のブリッジとして機能するツールです。このブリッジは、オブジェクト モデルを使用してリレーショナル データベース内の情報を管理する構造です。簡単に言うと、これは Microsoft が開発したフレームワークで、オブジェクトをデータベースに接続し、データを交換します。
Entity フレームワークで LINQ (統合言語クエリ) クエリを使用すると、オブジェクトに対する強力なクエリが得られます。 Entity フレームワークによって提供されるサービスは、主に変更追跡、ID 解決、クエリ変換です。Entity フレームワークの主な目的は、アプリケーション開発者がデータ操作に忙殺されすぎずにアプリケーション側に集中できるようにすることです。非常に単純な例として、従来の ADO.NET アプリケーションで接続を開いたり閉じたりする責任は、開発者にあります。ただし、エンティティ フレームワークを使用すると、そのような操作が妨げられることはありません。クエリを準備し、エンティティ フレームワークを介してデータベースに送信します。
Entity Framework は、これに 3 つの異なるプロジェクト開発方法を使用します。
Model First = この方法では、Visual Studio に空のモデル ファイル (.edmx) を追加することで、このモデルでデータベースを設計できます。コンパイル手順で指定されたスクリプト ファイルによってデータベースが作成されます。
データベースファースト = この方向では、以前に作成したデータベースをモデルとしてプロジェクトに接続することにより、Entity Framework によって必要なクラスが作成されます。
このフォルダーでは、最初にデータベースの例を示しました。 GitHub ページ。
Code First = このメソッドは、Visual Studio 環境でクラスの作成を開始することによって実行されるメソッドです。私たちのデータベースはこれらのクラスから派生しています。ここで、開発者はクラスの作成中に属性を使用してマッピング操作を行うことができます。ちなみに、マッピングプロセスはテーブルに制約を定義するイベントです。属性に加えて、これらの操作をさまざまな方法で実行できます。たとえば、Fluent Api や Fluent Validation などのツールは、マッピング操作によく使用されます。
Entity Framework ライブラリを使用すると、データベース内のテーブルに対してクエリを実行してデータをフィルターできます。 T-SQL で実行できるクエリのほとんどは、Entity Framework で実行できます。
ここでは基本的な選択操作を示しました。 GitHub ページ。
Entity Framework ライブラリを使用して、T-SQL クエリとレポートの統合機能を使用することもできます。
ここでは基本的な集計関数を示しました。 GitHub ページ。
Code First 構造では、プログラミング言語の「クラス」構造はデータベースの「テーブル」構造に対応し、「プロパティ」構造はデータベースの「列」構造に対応します。また、属性のおかげで、データベース構造に検証を適用したり、列に特定の条件や制限を設定したりできます。最も重要なのは、プロジェクト内のモデルの自動制御を実感し、完全な制御で思い通りに使用できることです。
この件に関する私の例をここで見ることができます。 GitHub ページ。
ここで使用できる vir データベースを作成しました。
ここで確認できます。 GitHub ページ。
これは、レイヤード アーキテクチャ プロジェクトをより組織化し、コードの可読性を高め、チームワークを高め、エラー管理を容易にする構造です。実際、この構造により、私たちはプロジェクト作成を標準にしました。この構造は主に 3 つの層で構成されているため、今日では多層アーキテクチャ構造と呼ぶことができます。しかし、実際には 3 つの主要なレイヤーで構成されています。これらの層は次のとおりです。
-- データ層 -- ビジネス層 -- プレゼンテーション層
ここでは、database.GitHub Pages に対応するエンティティを作成しました。
ここでは、インフラストラクチャ層である GitHub ページを作成しました。
ここで UI を作成しました。GitHub Pages。
Dapper は、Stackoverflow によって開発されたマイクロ ORM ツールで、多くのデータベースをサポートします。 orm ツールは多くのことをそれ自体で実行するため、動作が少し遅くなります。特に交通量の多い港では好ましくありません。そのような場合には、Dapper が好まれるかもしれません。それは単一の「dll」です。では、マッピング用のインターフェースとは何でしょうか?また、設定ファイルも必要ありません。一言で言えば、シンプルかつ高速です。 Github でオープンソースとしてリリースされ、開発が続けられています。
--Dapperの最も重要な特徴は、そのパフォーマンスが非常に優れていることです。ほとんどの場合、この利点により、この方法が好まれます。
-- クエリを簡単に実行し、返された結果をオブジェクトに簡単にバインドできます。
-- 最も重要な欠点は、クエリがインラインで記述されるため、間違いが非常に起こりやすいことです。これには注意が必要です。さらに悪いことに、これらのエラーはビルド時ではなく実行時に発生します。
--Dapperでは、ほとんどのことを私たちが行います。開発者は、データベース、クエリ、プログラム側のアセット、およびオブジェクトのステータスを実行する必要があります。これにより、大規模プロジェクトの開発段階での開発コストとメンテナンスコストが大幅に増加します。
このリポジトリでは 2 つの方法を使用してみました。 1 つのリポジトリでは SQL のプロシージャを操作し、もう 1 つのリポジトリではプログラムにクエリを直接記述することでプロシージャを操作しました。
-- まず、SQL でデータベースを作成しました。
-- その後、プログラムで使用する方法に適した手順を作成しました。ここから見ることができます。 GitHub ページ
--私のプログラムでは、プロシージャで使用するレイヤーとアセット、リポジトリも作成しました。ここで重要なことは、プロシージャとその中で使用するパラメータを正しく指定することです。そうしないと、大量のエラーが発生します。ここから見ることができます。 GitHub ページ
-- 「connection」でデータベースとの接続を作成しました。ここから見ることができます。 GitHub ページ
-- 最新のユーザー インターフェイスを作成し、必要なアクションを実行しました。ここから見ることができます。 GitHub ページ
ここでは、必要な操作を SQL で直接実行するクエリを作成しました。ここでクエリを記述するときは、非常に注意する必要があります。エラーが発生すると、多くの時間が無駄になる可能性があります。パラメータに関しては、クエリ内のパラメータの一致する値が正しい必要があります。しかし私にとって、Dapper における例外は非常に自明です。故障箇所を簡単に見つけられるのは本当に助かります。
ここから見ることができます。 GitHub ページ
ここでは、ユーザー インターフェイスでのアクションを示しました。
ここから見ることができます。 GitHub ページ