C# SQL 接続チュートリアル：Dapper + SQL Server データベースの説明

プロジェクトのセットアップとクリーンアップ

Timは最初にソリューションの構造を確認し、前回のレッスンで行った変更を確認します。 Program.csでは、SQL Serverとテキストファイルデータベースの両方に接続するコードを追加し、データベース接続を即座にテストできるように起動フォームを"Create Prize"フォームに変更したと説明しています。

次に、プロジェクト構造を整理し、2つのフォルダーを作成します。

• モデル

• データアクセス

これはソースコードの機能には影響しませんが、組織化を助けると指摘しています。 プロジェクトに後ほど戻るとき、クリーンな構造と一貫した命名がメンテナンスと拡張をはるかに簡単にします。

なぜDapper?

Timは、SQL接続にORM（オブジェクト関係マッピング）としてDapperを使用すると説明しています。 Dapperは生のSQLコマンドとEntity Frameworkのようなより高レベルなORMの間に位置します。

TimはDapperを好む理由は以下の通りです。

• 生のADO.NETとほとんど同じ速さ

• Entity Frameworkよりもシンプル

• 不必要な複雑さと大量のボイラープレートコードを回避

特に小規模なアプリケーションでは、Entity Frameworkは遅くて重いことがあると述べています。 彼のプロジェクトでは、Dapperは性能とシンプルさの適切なバランスを提供します。

Dapperのインストール

TimはVisual StudioのNuGetパッケージマネージャーを通じてDapperをインストールする方法を示しています。 インストール後、Dapperはプロジェクトの参照に表示され、SQL接続コードはクリーンで読みやすくなります。

接続文字列の追加

Dapperを使用するには、接続文字列が必要です。 TimはそれをUIプロジェクトのapp.configファイルに追加します。ライブラリプロジェクトではないのは、ライブラリがDLLであり独自の設定を持たないからです。

接続文字列には以下が含まれます。

• Data Source（サーバー名またはマシンドメイン名）

• Initial Catalog（データベース名）

• Integrated Security（Windows認証）

• 接続タイムアウト

• User IDとPassword（Windows認証を使用していない場合）

Timの例では、Windows認証を意味する信頼済み接続を使用しています。

データ ソース=SQL2016;初期カタログ=トーナメント;統合セキュリティ=True;

彼は、この方法がSQL Serverユーザーの資格情報をファイルに保存するリスクを避けることを強調しています。

GlobalConfig: 接続文字列の取得

接続文字列を取得するために、TimはGlobalConfigにメソッドを追加します。

public static string GetConnectionString(string name)
{
return ConfigurationManager.ConnectionStrings[name].ConnectionString;
}

このメソッドは、設定ファイルから接続文字列を取得して返します。 Timはまた、必要なSystem.Configuration参照を追加しています。

SQL接続の作成

Timはプレースホルダーコードを削除し、以下を使用して実際のSqlConnectionを作成します。

using (IDbConnection connection = new SqlConnection(
GlobalConfig.GetConnectionString("tournaments")))
{
    // SQLロジックここに
}

彼はIDbConnectionインターフェイスを使用しているため、データベースのタイプ（SQLまたはテキストファイル）を変更し、コアコードを変更せずに済みます。

usingブロックは重要です。これは、コードがブロックを抜けるときに接続が自動的に閉じられることを保証します。 これは、接続プールを使い果たす可能性のあるオープンな接続やデータベースサーバーでエラーを引き起こすことを避けるためです。

ストアドプロシージャの作成

C#内で生のSQLを書く代わりに、Timはストアドプロシージャを使用します。 これにより、SQLロジックがデータベースに保持され、SQLインジェクションのリスクが減少します。

彼は以下の名前のストアドプロシージャを作成します。

dbo.SP_Prizes_Insert

この手順は、賞のテーブルに一致するパラメータを取ります。

• @PlaceNumber

• @PlaceName

• @PrizeAmount

• @PrizePercentage

• @ID (出力)

出力パラメータは、次のように生成されたIDを返します。

SELECT @ID = SCOPE_IDENTITY()

これにより、新しいレコードIDがC#アプリケーションに返されることが保証されます。

Dapperでの動的パラメータ

C#に戻り、TimはDapperのDynamicParametersを使用してストアドプロシージャにパラメータを送信しています。

var p = new DynamicParameters();
p.Add("@PlaceNumber", model.PlaceNumber);
p.Add("@PlaceName", model.PlaceName);
p.Add("@PrizeAmount", model.PrizeAmount);
p.Add("@PrizePercentage", model.PrizePercentage);
p.Add("@ID", 0, dbType: DbType.Int32, direction: ParameterDirection.Output);

IDは出力としてマークされており、Dapperはパラメータマッピングを処理します。

ストアドプロシージャの実行

彼はストアドプロシージャを実行しています。

connection.Execute("dbo.SP_Prizes_Insert", p, commandType: CommandType.StoredProcedure);

Executeは挿入を行い、SELECT文のように行を返さないために使用されます。

実行後、コードはIDを取得します。

model.ID = p.Get<int>("@ID");
return model;

テストと結果

Timはアプリケーションを実行し、フォームに入力し、賞を作成をクリックします。データはSQL Serverデータベースに正常に挿入されます。 彼は両方をテストします。

• 賞金額

• 賞金率

両方が動作し、データベース接続とストアドプロシージャが正しく機能することを証明しています。

設計課題: 複数のデータコネクタ (1:01:50)

Timは設計上の問題を強調しています。SQLとテキストファイルのコネクタを同時に使用すると、IDが不整合になることがあります。

したがって、彼は設計を変更し、1つのコネクタのみが一度に実行されるようにします。彼はenumを追加します。

データベースタイプ
{
SQL,
テキストファイル
}

これにより、アプリは常に一貫したデータベースタイプを使用し、異なるソースからのデータベースデータの混在を防ぎます。

結論

Tim Coreyのレッスン10は、Dapperを使用してC#アプリケーションをSQL Serverに接続する現実的なアプローチを示しています。 彼がカバーするのは以下です。

• 接続文字列の追加

• SqlConnectionの使用

• 接続の安全な開閉

• ストアドプロシージャの使用

• SQLインジェクションの回避

• 複数のデータソースに対する適切なアーキテクチャ

C#をSQL Serverデータベースに接続するクリーンで速く、メンテナンスしやすい方法を探しているなら、これのレッスンは完璧なガイドです。