はじめに
今回はタイトルにある通りSmartF開発でEntityFrameworkを採用しなかった話を書こうと思います。
SmartFはC#で開発をしていまして、EntityFrameworkはC#でデータベースを使う場合においてよく利用されているものと思っております。実際、私もSESの頃にはEntityFrameworkを使ったプロジェクト開発を何件も行いました。
「EntityFrameworkとは？」という方もいらっしゃると思いますので、Geminiに聞いた結果を記載しておきます。
Entity Frameworkとは、
- データベースのデータをC#のオブジェクトのように扱えるようにする技術（ORM）です。
- LINQを使って直感的にデータを操作でき、SQLを直接書く手間を減らします。
- データベースの種類を意識しにくくし、開発の生産性を向上させます。
デメリットは
- 複雑な処理では、自動生成されるSQLの効率が悪く、性能が出にくいことがあります。
- 高機能な反面、学習コストが高く、内部の挙動が分かりにくい場合があります。
- 細かくSQLを制御したい場合、ORMの抽象化が逆に手間になることもあります。
ちょっと脱線しますが、AIを使うことで、長年の利用経験の中で得られた成功体験が大して貴重なものではない時代になってしまい仕事が楽になる気持ちと同時に寂しい気持ちにもなる今日この頃です。
とはいえプロダクトでの採用可否の意思決定もAIで出来るのかというと、そこはまだ難しい面もありますので、EntityFrameworkのどのあたりがSmartF開発にマッチしなかったのかを紹介したいと思います。
その１ 下位互換とコードファーストが両立しない
Blazor開発なのでフレームワークは .NET Framework Core になるのですが、現行のAPIサーバが.NET Framework4.8 なのでプロジェクトに互換性がありません。なので、データ層を新規にプロトタイプ開発しました。この活動の中でEntityFrameworkのコードファーストを導入するプロトタイプが作られていました。
「コードファーストで作りたい！」というエンジニアの気持ちも分からなくはないのですが、今実際に動いているプロダクトとの互換性や、将来同じデータベースを参照する別プロダクトを複数発足する際にも同様の課題が発生することになるためデータベースファーストで行くという方針にしました。
その２ 既存課題が胡乱になる
SmartFのデータ層は「Dapper + 2Way-SQL」方式で実装しています。
ここをEntityFrameworkに置き換えると、今のデータベース操作の性能を損なうリスクがあります。今時点での性能にまだまだ課題がありますが、この課題が解決していない状態で更なるアイデアを載せる方法論を取ると、結局何が問題だったのかが分からなくなります。
SmartFの特性として、品番マスタ系のデータが多いお客様も入れば生産指示で使う部品種類が多いお客様がいたりと、データベースの中身の特徴が異なるため、今のSQLが何に効果があって何が苦手なのかをしっかりとPoCした上で性能課題に取り組みたいので、今回のタイミングでの導入は見送りました。
その３ EntityFrameworkで何を解決したかったのか
ORMによる抽象化が却って実際に動くSQLへの直感性を損なってしまう、というのはGeminiも教えてくれますが、SmartFには複雑なSQLがあるため、そこの直感性が損なわれることがけっこうなリスクになります。
また、簡単なSQLならEntityFrameworkを使わなくても"そもそも簡単"なので、どんな方法でも何とかなります。本質的な課題の解決に効かず、どんな方法でもパパっと作れてしまうような課題のためにアーキテクチャ採用するのは不適切な場合もあるのかなと思います。
EntityFrameworkでSQLをそのまま実行することも出来るのですが、それは、イマイチな意思決定を正当化するために余計は判断を追加することと同様ではなかろうか、というのが個人的な意見です。問題解決とは、なんでも前進思考すればいいわけでなくて「やらない」という判断のためも排他的思考も大事だと思います。
さいごに
以上、EntityFrameworkを採用しなかった話でした。
EntityFramework自体は、使いどころと使い方が適切であれば生産性を上げる強力なツールですが、強力なツールがどのような前提でも強力とは限らないので、アーキテクチャ採用にEntityFrameworkをご検討されている方の参考になれば幸いです。
Discussion