Microsoft の .NET 向け Entity Framework (EF) データベース ライブラリの次期メジャー バージョンでは、長期サポートが提供され、ライバルである Dapper と同等のパフォーマンスが実現される予定ですが、シニア プログラム マネージャーの Jeremy Likness 氏によると、この試みは「完全には達成されない可能性が高い」とのことです。
Entity Framework は、Microsoft のオブジェクト リレーショナル マッピング (ORM) ライブラリであり、下位レベルのデータベース ライブラリである ADO.Net の上に配置されます。
ORMを使用する理論は、データベースに対するCRUD（作成、取得、更新、削除）操作のコード記述という、面倒でエラーが発生しやすい作業の多くを開発者から軽減することです。ORMを使用することで、開発者はビジネスオブジェクトを表すクラスを操作し、必要に応じてORMにそれらの保存と取得を指示することができます。
問題を複雑にしているのは、EF（.NET Frameworkでも動作）からEF Core（.NET Coreのみで動作）への移行が困難だったことです。EFの最終バージョンは2017年の6.2でした。EF Coreは完全な書き換えであり、代替品ではありませんでした。データベースからモデルクラスを更新する機能など、EFの一部機能は、EF Coreのバックログに6年以上も残っていました。一方で、EF CoreにはEFにはない機能もいくつかあります。
Likness 氏によると、EF Core 6.0 は 2021 年 11 月に予定されており、.NET 6 と連携した LTS (長期サポート) リリースとなる予定です (.NET の将来のバージョンはすべて、.NET Framework ではなく .NET Core に基づいていることに注意してください)。
新機能には、SQL Server のテンポラルテーブル（データの変更履歴を保持するテーブル）のサポート、JSON 列のサポート、移行サポートの強化（コード内のオブジェクトモデルからデータベースを更新する機能）、EF 6.x で動作するすべてのクエリのサポートが含まれます。また、Microsoft のマルチモデル Azure データベースサービス向けの Cosmos DB プロバイダーの改善や、SQLite および SQL Server 向けの完全なフリーテキスト検索機能の実装も計画されています。
Likness 氏によると、ADO.NET に関する作業も進行中で、これには 1 回の操作で複数のクエリを送信するための新しいバッチ API が含まれており、接続プールと準備済みステートメントをサポートするために SQLite プロバイダーに改良が加えられているという。
「具体的な成果物は計画されていない」実験的な機能には、SQLServer.Core と呼ばれる「最新の .NET 機能」を使用して書き直された SQL Server ドライバーと、.NET での GraphQL のより優れたサポートが含まれます。
ダッパーを捕まえようとする
パフォーマンスも大きな課題です。計画には、コンパイル済みモデルや、EF Coreを「リンカーとAOT（事前コンパイル）でより快適に動作させる」ことが含まれます。AOTは事前コンパイルです。「TechEmpower FortunesベンチマークでDapperのパフォーマンスに匹敵する予定です」とLikness氏は明言し、「これは大きな課題であり、完全に達成できる可能性は低いでしょう」と付け加えました。
ORMは抽象化のレベルが様々です。EFは高度に抽象化されています。.NETの世界では、Dapperという代替手段があります。これは軽量で、「.NET用のシンプルなオブジェクトマッパー」と自称しています。Dapperでも開発者はSQLを記述する必要がありますが、結果と.NETオブジェクト間のマッピング処理はDapperが担います。パフォーマンスは生のADO.NETに匹敵するほどです。
ASP.Net Coreのスキャフォールディングアイテムでは、データベース機能を素早く追加するためにEntity Frameworkを使用します。
TechEmpowerのベンチマークを見ると、単一クエリで最高パフォーマンスの.NETスタックはASP.NET CoreとADOの組み合わせで、318,164というスコアを獲得しています。Dapper ORMは247,280です。EFの最高パフォーマンスは116,496です。これはPostgreSQLを使用した場合のスコアです。ライセンス上の理由から、Microsoft SQL Serverはベンチマークに含まれていません。
Dapperに追いつくためには、EF CoreはデータベースサーバーにSQLを単純に送信する場合と比べてオーバーヘッドを削減する必要があります。EFが提供する価値の鍵となる機能をバイパスすることなく、これを実現することはおそらく不可能でしょう。これはEFの生のSQLクエリを使用することで既に可能ですが、通常のEF使用時のパフォーマンスの問題は解決されません。
ORM は、開発者 Joel Spolsky が「漏れやすい抽象化」と呼んだものの一例です。
同氏によると、抽象化とは「裏で起こっているはるかに複雑なことを単純化したもの」であり、漏洩は「抽象化では完全には防ぐことができないもの」を表している。
Spolsky 氏は、データベース クエリの共通言語である SQL を、漏れやすい抽象化であると説明しました。これは、ORM を漏れやすい抽象化の漏れやすい抽象化にするものです。
パフォーマンスはしばしば問題となります。ORMはあらゆるケースに対応する必要があり、アプリケーションが実際に必要とする以上のデータを取得しがちで、結果として速度低下につながります。多くの場合、これはボトルネックにはならないため大きな問題にはなりませんが、高負荷のWebアプリケーションのような状況では致命的です。
2 つ目の問題は、ORM 自体の複雑さが、ユーザーを保護しようとしている複雑さと同じくらい悪影響を及ぼす可能性があることです。
EF の多対多リレーションシップについて調べてみると、SQL の JOIN 構文は習得が難しくなく、より正確に使用できるという結論に達するかもしれません。これに対する反論としては、理想的な ORM であれば、ほとんどの開発者が実現できるよりも最適化された SQL を生成できる可能性があるというものがあります。
開発者はアプリケーション内でEFをどのように最適化するのでしょうか？EFを最大限に活用する方法を学ぶこともあれば、EFが生成するSQLを検査することも含まれます。つまり、熟練したEFユーザーであっても、SQLを理解する必要があるということです。
開発者が単純なアプリケーションの開発を終えると、EF のパフォーマンスと複雑さは軽視できません。Microsoft は、.NET プラットフォームの提示方法とドキュメント化において、SQL Server と同様に EF を推奨しています。
したがって、EFのパフォーマンスは.NETのパフォーマンスの認識にも影響を与えます。EFは一部のユースケースにおいて常に高い生産性を実現する役割を果たしますが、Dapperの優れた結果を考えると、MicrosoftはDapperに匹敵するパフォーマンスを目指して失敗するよりも、この代替手段をより重視することを検討すべきでしょう。®
ブートノート
Dapperは、開発者に人気のコピー＆ペースト式のQ&Aサイト、StackOverflowで誕生しました。StackOverflowの共同創設者はSpolsky氏です。しかし、Dapperを最初に開発したのはSam Saffron氏で、彼は後にRuby on RailsのディスカッションアプリケーションであるDiscourseを創業しました。
