WebSurfer's Home

トップ > Blog 1   |   Login
Filter by APML

ASP.NET Core で DateOnly 型を使用

by WebSurfer 19. July 2022 13:28

先の記事「PostgreSQL で Movie チュートリアル (CORE)」で書きましたように、Npgsql 6.0 の timestamp with time zone 型と .NET の DateTime 型の扱いの不整合のため例外がスローされるという問題があります。

その記事では臨時処置的に Npgsql を 6.0 より前の動作に戻すオプションを追加して解決しましたが、恒久処置的には .NET の DateTime 型を DateOnly 型に変えて、対応する PostgreSQL の型を date 型にするべきではないかと思いました。

というわけでそれを試してみましたので以下に顛末を書いておきます。ASP.NET Core はまだ DateOnly 型を十分にサポートしてないようで、すんなりとはいかなかったです。ASP.NET Core で DateOnly 型を使うのは時期尚早なのかも。

(1) DateTime 型を DateOnly 型に変更

Movie クラスの ReleaseDateプロパティの DateTime 型を DateOnly 型に変更します。

DateTime 型を DateOnly 型に変更

(2) Add-Migration の実行

ソリューションをリビルドしてから、Visual Studio のパッケージマネージャーコンソールで Add-Migration DateOnly コマンドを実行します。結果、以下の画像の通り DateOnly クラスが Migrations フォルダに自動生成されます。

Add-Migration の実行結果

Movie クラスの ReleaseDate プロパティの DateOnly 型に該当する PostgreSQL の型は date となっています。

なお、Add-Migration DateOnly の DateOnly という名前は任意に指定できます。指定した名前で xxxxx_DateOnly.cs (xxxxx は作成日時) という名前のファイルが作成され、それに DateOnly という名前のクラスが定義されます。

(3) Update-Database の実行

Visual Studio のパッケージマネージャーコンソールで Update-Database コマンドを実行します。

Update-Database の実行結果

上の画像の ReleaseData 列を見てください。Update-Database の実行前は timestamp with time zone 型であったものが date 型に変更されています。

(4) プロジェクトの実行

以上で完了のはずなのですが、プロジェクトを実行して Index 画面を表示すると ReleaseDate の表示が変でした。html ソースは以下のとおりで、DataOnly のプロパティが表示されます。

<div class="display-label">Year</div>
<div class="display-field">2022</div>
<div class="display-label">Month</div>
<div class="display-field">7</div>
<div class="display-label">Day</div>
<div class="display-field">10</div>
<div class="display-label">DayOfWeek</div>
<div class="display-field">Sunday</div>
<div class="display-label">DayOfYear</div>
<div class="display-field">191</div>
<div class="display-label">DayNumber</div>
<div class="display-field">738345</div>

Movie クラスの ReleaseDate プロパティに DisplayFormat 属性を付与してみましたが何も効果はなかったです。

さらに、Create, Edit 操作では、ブラウザからは期待通りに ReleaseDate=2022-07-18 という形で送信されるものの、アクションメソッドの引数には 0001/01/01 が渡される、すなわちモデルバインディングできてないという問題がありました。

ググって調べてみると、DateOnlyTimeOnly.AspNet という NuGet パッケージが見つかりました。Web API 用とのことですが、とりあえず試してみることにしました。

DateOnlyTimeOnly.AspNet

NuGet パッケージをインストールしたら、Program.cs で UseDateOnlyTimeOnlyStringConverters を AddControllers のオプションとして登録します。

DateOnlyTimeOnly.AspNet

結果、Index 画面の ReleaseDate は 2022/07/18 という形で表示されるようになりました。Create, Edit 操作でのモデルバインディングも正しく行われるようになりました。

もちろん、AppContext.SetSwitch("Npgsql.EnableLegacyTimestampBehavior", true); は削除しても例外は出ず、Create, Edit とも成功します。

ホントはこのような追加のパッケージなしでも DateTime 型を使った場合と同様に動くべきだと思うのですが・・・

Tags: , , , ,

CORE

PostgreSQL で Movie チュートリアル (CORE)

by WebSurfer 18. July 2022 18:48

データベースに PostgreSQL を利用して、Micorsoft の ASP.NET Core MVC のチュートリアル「ASP.NET Core MVC の概要」および「パート 4、ASP.NET Core MVC アプリにモデルを追加する」に従ってアプリを作る方法を書きます。

Movie アプリ

先の記事「MySQL で Movie チュートリアル (CORE)」、「SQLite で Movie チュートリアル (CORE)」でデータベースにそれぞれ MySQL, SQLite を使った例を書きましたが、この記事はその PosrgreSQL 版です。

PostgreSQL 本体は先の記事「PostgreSQL をインストールしました」でインストールした v14.4 を使います。

(1) プロジェクトの作成

チュートリアル「ASP.NET Core MVC の概要」の通り、Visual Studio 2022 のテンプレートを利用して対象のフレームワークは .NET 6.0認証「なし」の ASP.NET Core MVC アプリを作成します。

対象のフレームワークを .NET Core 3.1 とか .NET 5.0 にした場合は NuGet パッケージのバージョンの選び方に注意してください。違うとスキャフォールディングでエラーになるかもしれません。

また、認証を「個別のアカウント」にすると SQL Server を利用した Entity Framework 関係のパッケージがインストールされ話がややこしくなりますので、まずは認証は「なし」でやってみることをお勧めします。

(2) モデルの定義とスキャフォールディングの実行

チュートリアル「パート 4、ASP.NET Core MVC アプリにモデルを追加する」に従って、モデル(エンティティ)クラスの定義をプロジェクトに既存の Models フォルダに追加します。

using System.ComponentModel.DataAnnotations;

namespace PosrgreSqlMovie.Models
{
    public class Movie
    {
        public int Id { get; set; }
        public string? Title { get; set; }

        [DataType(DataType.Date)]
        public DateTime ReleaseDate { get; set; }
        public string? Genre { get; set; }
        public decimal Price { get; set; }
    }
}

次に、Microsoft.EntityFrameworkCore.Design を NuGet からインストールします。この記事では、この記事を書いた時点での最新版 6.0.7 を使いました。対象のフレームワークが .NET Core 3.1 とか .NET 5.0 の場合は、Microsoft.EntityFrameworkCore.Design のバージョンもそれに合わせるのが良さそうです。バージョンが違うとスキャフォールディングでエラーになるかもしれません。

チュートリアルの通り Visual Studio でスキャフォールディングを実行すると以下の操作が自動的に行われます。(コードジェネレータ関係のエラーが出る場合がありますが、その際は下の追加 NuGet パッケージがインストールされていることを確認してから再度スキャフォールディングを行うと成功すると思います)

  1. 他に必要な NuGet パッケージ(Microsoft.EntityFrameworkCore.SqlServer, Microsoft.EntityFrameworkCore.Tools, Microsoft.VisualStudio.Web.CodeGeneration.Design)の追加
  2. Data フォルダにコンテキストクラスの作成
  3. Program.cs ファイル (.NET 5.0 以前の場合は Startup.cs ファイル) でコンテキストクラスの登録
  4. appsettings.json ファイルへの接続文字列の追加
  5. CRUD 操作に必要な Controller / View 一式の生成

SQL Server の場合は上記でプロジェクトは完成ですが、PostgreSQL を利用する場合は上の 1, 3, 4 に以下の変更を行う必要があります。

(3) NuGet パッケージの追加

NuGet パッケージ Npgsql.EntityFrameworkCore.PostgreSQL をインストールします。その結果が以下の画像です。

NuGet パッケージ

スキャフォールディングで自動的に追加される Microsoft.EntiryFrameworkCore.Tools のバージョンがランタイムのバージョンより古い場合は Migration 操作の際警告が出るのと思いますので更新してください。

注意: Microsoft.EntityFrameworkCore.SqlServer はモデルクラスの定義によってはスキャフォールディングで必要になるケースがあるようです。具体的にどのようなケースで必要になるかは調べ切れてませんが、データアノテーション属性が関係しているような感じです。なので、この先モデルの定義を変更して Migration ⇒ スキャフォールディング操作を繰り返すなら、Microsoft.EntityFrameworkCore.SqlServer は残しておいた方が良さそうです。

(4) Program.cs ファイルの修正

スキャフォールディング操作で Program.cs ファイル (.NET 5.0 以前の場合は Startup.cs ファイル) でサービスに自動的にコンテキストクラスが登録されますが、それは SQL Server 用なので、以下のように PostgreSQL 用に変更します。

UseSqlServer を UseNpgsql に変更

コンテキストクラスの登録はコントローラーへの DI に必要です。登録してあれば、フレームワークがクライアントからの要求を受けてコントローラーを初期化する際、コンテキストクラスを初期化してコンストラクタ経由で渡してくれます。

(5) 接続文字列を PostgreSQL 用に変更

スキャフォールディング操作で appsettings.json ファイルに接続文字列が自動生成されますが、それは SQL Server (LocalDB) 用なので PostgreSQL 用に変更します。

接続文字列の変更

データベース名は任意です。上の画像のように Database=Movie というようにデータベース名を指定すると、Entity Framework Code First の機能を使って Movie という名前のデータベースを新たに生成し、そこに必要なテーブルを生成してくれます。

(6) Add-Migration の実行

ソリューションをリビルドしてから、Visual Studio のパッケージマネージャーコンソールで Add-Migration InitialCreate コマンドを実行します。結果、以下の画像の通り InitialCreate クラスが Migrations フォルダに自動生成されます。

Add-Migration の実行結果

Movie クラスの ReleaseDate プロパティ、Price プロパティの型はそれぞれ DateTime、decimal ですが、PostgreSQL にはそれらに該当する型がないらしく、それぞれ timestamp with time zone, numeric となっています。(後述しますが、それにより問題が出ます)

Add-Migration InitialCreate の InitialCreate という名前は任意に指定できます。指定した名前で xxxxx_InitialCreate.cs (xxxxx は作成日時) という名前のファイルが作成され、それに InitialCreate という名前のクラスが定義されます。

(7) Update-Database の実行

Visual Studio のパッケージマネージャーコンソールで Update-Database コマンドを実行します。これにより以下の画像の通り PostgreSQL データベースが生成されます。

Update-Database の実行結果

接続文字列で Database=Movie とした通り Movie という名前でデータベースが生成され、InitialCreate クラスの name: "Movie" で指定された名のテーブルが生成されています。

Movie クラスの ReleaseDate プロパティ、Price プロパティに該当する Movie テーブルのフィールドの型は、上のコードの InitialCreate クラスの指定通りそれぞれ timestamp with time zone, numeric となっています。

(8) プロジェクトの実行

これで完成と思って、プロジェクトを実行し Create 画面を表示してレコードを追加しようとしたら・・・

InvalidCastException: Cannot write DateTime with Kind=Unspecified to PostgreSQL type 'timestamp with time zone', only UTC is supported. Note that it's not possible to mix DateTimes with different Kinds in an array/range. See the Npgsql.EnableLegacyTimestampBehavior AppContext switch to enable legacy behavior."

・・・という例外がスローされて失敗します。(汗)

エラーメッセージでググって調べてヒットした記事「Date and Time Handling」によると "Npgsql 6.0 introduced some important changes to how timestamps are mapped" とのことで変更があったようです。Npgsql 6.0 より前の動作に戻すには以下のコードを追加すると書いてあります。

AppContext.SetSwitch("Npgsql.EnableLegacyTimestampBehavior", true);

ステップ (2) で Data フォルダに自動生成されたコンテキストクラスに上のコードを追加することで、臨時処置的な解決策かもしれませんが、例外はスローされなくなります。

レコードの Create 結果

上の修正を加えた後でプロジェクトを実行して、Create 画面でレコードを 3 件追加し Index 画面でその一覧を表示したのがこの記事の一番上の画像です。

上の例外に対する恒久処置ですが、Movie クラスの ReleaseDateプロパティの DateTime 型を DateOnly 型に変えて、対応する PostgreSQL の型を date 型にするという記事を目にしました。それをやってみた結果を別の記事「ASP.NET Core で DateOnly 型を使用」に書きましたので、興味があれば見てください。

Tags: , , , ,

CORE

サーバー側で応答コンテンツの取得 (CORE)

by WebSurfer 7. July 2022 16:30

ASP.NET Core Web アプリの応答ボディの文字列を、サーバー側でのログなどの目的で、取得する方法を書きます。先の記事「サーバー側で応答コンテンツの取得」の ASP.NET Core 版です。

応答ボディの文字列

.NET Framework 版 ASP.NET で利用した HttpModule、HttpResponse.Filter プロパティ、HttpResponse.OutputStream プロパティは ASP.NET Core ではサポートされていません。

代わりにカスタム MiddlewareHttpResponse.Body プロパティを使って同様なことを行います。

ただし、HttpResponse.Body プロパティで取得できる Stream は CanRead, CanSeek が false になっており読むことができないという問題があります。

その解決に、先の記事「HttpRequest.Body から読み取る方法 (CORE)」で書いた EnableBuffering メソッドが使えるかと思ったのですが、応答側 HttpResponse ではサポートされていませんでした。

やむを得ず、Middleware で next.Invoke の前に応答ボディ用の Stream を MemoryStream に差し替えて、next.Invoke の後で MemoryStream に書き込まれた応答ボディを取得するという手段を取りました。

そのサンプルコードは以下の通りです。デバッグ実行すると上の画像ように「出力」ウィンドウに応答ボディの文字列が取得できます。

namespace MvcCore6App3.Middleware
{
    public class ResponseContentLogMiddleware
    {
        private readonly RequestDelegate _next;

        public ResponseContentLogMiddleware(RequestDelegate next)
        {
            this._next = next;
        }

        public async Task InvokeAsync(HttpContext context)
        {
            // この例では Home/Privacy のみログを取るという前提
            if (context.Request.Path.ToString().Contains("/Home/Privacy"))
            {
                // 応答ボディの Stream を取得して保持
                Stream responseStream = context.Response.Body;

                // 応答ボディの文字列を取得する
                string bodyContent = "";

                try
                {
                    using (var memoryStream = new MemoryStream())
                    {
                        // 応答ストリームを MemoryStream に差し替えて、それに
                        // 応答ボディを取得。_next.Invoke の前でないとダメ
                        context.Response.Body = memoryStream;

                        await _next.Invoke(context);

                        // この時点ではすでに MemoryStream には応答ボディは
                        // 書き込まれている

                        if (memoryStream.Length > 0L &&
                            memoryStream.CanRead &&
                            memoryStream.CanSeek)
                        {
                            memoryStream.Position = 0L;
                            var reader = new StreamReader(memoryStream);
                            bodyContent = await reader.ReadToEndAsync();

                            // 確認用(デバッグ実行で Visual Studio の「出力」
                            // ウィンドウに表示される)
                            System.Diagnostics.Debug.Write(bodyContent);

                            memoryStream.Position = 0L;

                            // MemoryStream に取得した応答ボディのバイト列を
                            // responseStream にコピー
                            await memoryStream.CopyToAsync(responseStream);
                        }
                    }
                }
                finally
                {
                    // 上のコードで MemoryStream に差し替えた応答ボディの
                    // Stream を元に戻す
                    context.Response.Body = responseStream;
                }
            }
            else
            {
                // 何もしない場合でも以下のコードは必須。これが無いとミドル
                // ウェアのチェーンの途中で止まってしまう
                await _next.Invoke(context);
            }
        }
    }
}

上の Middleware が動くようにするには Program.cs (.NET 5.0 以前では Startup.cs) での設定が必要です。以下のコードで「追記」とコメントした一行を追加します。

// ・・・前略・・・

app.UseAuthentication();
app.UseAuthorization();

// 追記
app.UseMiddleware<ResponseContentLogMiddleware>();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");
app.MapRazorPages();

app.Run();

HttpResponse.Body プロパティで取得できる Stream が読めないのは、HttpRequest.Body と同様に、"lightweight and performant as possible" ということを狙ってのことではないかと思います。

なので、上記のようなことをすると性能上の劣化が生じるかもしれません。どうしてもログが必要と言うような場合にとどめておいた方が良さそうな気がします。

Tags: , , ,

CORE

About this blog

2010年5月にこのブログを立ち上げました。その後ブログ2を追加し、ここはプログラミング関係、ブログ2はそれ以外のトピックスに分けました。

Calendar

<<  October 2022  >>
MoTuWeThFrSaSu
262728293012
3456789
10111213141516
17181920212223
24252627282930
31123456

View posts in large calendar