わけあってここ3日ほどEntity Framework Coreを触ってます。

この記事は想い出的ななにかがメインであって、特に技術的なアレは最後にちょろっとだけ書いてるただの雑談記事です

DataTableと技術的にレガシーな現場


触っていて思い出したのがDataTableです。前職ではVB.NETでDBから取得したデータをごにょごにょして(この辺り詳しく書くのもアレなのでふわっと書きます)アレアレしていたのですが、この時にDataTableを使用する場合がありました[1]

この、DBから取得したデータをDataTable など[1:1] でごにょごにょしてアレアレするのが当時かなり疑問でして、しかしながらその現場しか(前職ではずっと同じ部署で製品開発~導入までやってました)知らなかった私には具体的にどう対応するのが世の中のスタンダードなのかわからず[2]、いろいろと試行を巡らせたり調べたりする日々が続きました。その結果、ORMなるスーパースゴイゴッドツールが存在するということを知りました。

しかしながら、当然そういった現場でORMなどという謎のスーパースゴイゴッドツールを導入できるわけはないですし、そもそも私自身がORMはスーパースゴイゴッドツールでなんかわからんけどスーパースゴイという認識で、.NETだとEntity Frameworkとかいうのがあるらしいんですよくらいの要するによくわかってない状況でした[3]

「なにいってだこいつ」と思われるかもしれないですが、まあ、一昔前のIT業界はたぶんこういうの普通だった[4]んですよ。Jenkins投入して部会で説明したとき「お前OSSとかハアアアアアンンンンンンン???我々の常識からすると信じられないすね。ハアアアアアンンンンンンン???サポートどうするの[5]ハアアアアアンンンンンンン???」みたいなリアクションされたの覚えてるんですよ。他にも書きだすときりがないくらいいろんなアレがあるんですよ。ちょっと昔のIT業界に従事してた人(今もそういう現場は多いと思いますが)ならみんな経験したことあると思うんですよ。バージョン管理ツールなにそれおいしいの。とか。完全に余談なんですけど…

オレオレORMっぽいなにか


そんな感じだった私が結局どうしたかというと、自作でORMっぽいものを作ってみた[6]んですね。細かいところまでは覚えていないのですが、下記のような感じだったと思います。

  • Select(*), Insert, Update, Deleteできる
  • 属性を用いてカラムとプロパティをマッピングした
  • テーブルのカラムが多すぎてクラスを書くのがつらかった
  • VB.NETのバージョンが古く、自動実装プロパティが使えずなおさら厳しかった

この辺は覚えてます。取得時のデータと現在の値を比較して差分のみUpdateする。とかそんな感じだったと思います。そうそう、そんな感じだったんですよ。懐かしいなぁ…。この時にデザインパターンのMementoを学んだ記憶があります。また、そもそもこの実装をするまで継承とか使ったことがなかった気がします[7]。確か、ジェネリクスやリフレクション、属性とかLINQもこれで初めて使ったと思います。最終的にこの実装したアレを投入したかというと部分的にコッソリ投入したのですが、問題なく動いたので問題なかった[8]んだと思います。

月日は経って…


さて、月日は経ち、Entity Framework Coreを触ってみて感じた下記のような感想を抱きました。

  • そうそう、これがやりたかったんだよ
  • 筋は悪くなかったのでは

まず第一の感想は「そうだよ、オレはよ~~~当時こういうのをやりたかったんだよ~~~これがスーパースゴイゴッドツールだよ~~~」という感じですね。その思いだしで懐かしくなって書いた記事がこの記事です。

次に前述のとおり、当時属性を用いてマッピングをしたのですが、Entity Frameworkも同様のアプローチをとって(ちなみにマッピングするアプローチはこれを含めて限られていると思う)おり、もしかして「当時もそこまで筋は悪くなかったのでは?」と思いました。いや、だって当時の周りと私のレベルからすると属性とかオーバーテクノロジーでそれ使ってマッピングするとかもはや発想がヤバくてヤバくないですか??

Entity Framework Coreについて


ついでなので、Entity Framework Coreについて少し書いておきます。

諸事情で.NETFramework(≠ Core)で実装することになりました。まず、Coreとついているので.NETCoreでしか動作しないのではないかという疑問が浮かびましたが、Entity Framework Core は .NET Frameworkでも動作します

ただし、データベースからのクラスの生成(これをデータベースファーストと言います。逆にコードからテーブル生成するのをコードファーストと言います)は.NETCoreしか対応していない(???)のか、できませんでした。まあ、時間がなかったのでちゃんと試してないというのもあるんですが…

また、コードのサンプルが少ないですが海外のMS MVPの人が豊富なサンプルを書いてくださっているので、このサンプルを見ると楽だと思います。特にJOIN周り。

後はJOINの時にToListしないとArgumentNullExceptionがでる???とかいう疑惑があります。(回答にCROSS JOINと書かれてますが、たぶんJOIN全般だと思います。)ただ、前述のMVPの方のサンプルもToListしておらず、そもそもToListするとSQLのJOINではなくコレクションのJOINとなりパフォーマンスがアレなのでは???という疑惑があり、つまるところ、私の実装が誤っているのでは疑惑があり、この辺どうなんすかね…気が向いたらどっかで記事にするかもしれないです。

追記: どうもEntity Framework Coreのバグっぽいです

その他、ドキュメントが「ザ・機械翻訳」でかなり怪しいのでプルリクチャレンジしたい人には絶好のプルリク先だと思います。興味ある人はやってみたらいいんじゃないでしょうか。リポジトリはここです。ただし、本家の英語を機械翻訳しているだけだと思うので、本家が更新されたら上書きで再度機械翻訳になるのではないのか…???という気がしますが…。この辺どうなんですかね…。

感想


こう思い返せば、まあ、えらい成長したなぁ…としみじみと思うとともに、もっと早い段階でもっと良い開発現場に携わりたかった[9]という想いもあり、なんとも複雑な気持ちになります。

おわり。


  1. 使用する場合があったんですよ…場合があった…なんともいえない響きですね… ↩︎ ↩︎

  2. 書くまでもないのですが、私以外の誰もわかってなかったですし、そもそも疑問に思ってる人間が一握りでした。 ↩︎

  3. まあ、いまもよくわかっ…(くぁwせdrftgyふじこlp ↩︎

  4. 前職は今でもそんな気がしますが…今、前職に戻ったら(単純な技術面だけでは)無双できる自信がある ↩︎

  5. どうせサポートあっても高いお金だけ払って使わないのになぜそこを心配するのか… ↩︎

  6. もちろんコードはお察しだったとおもいます。また、今なら迷わず説得してEntity Frameworkを導入します。 ↩︎

  7. いや、あのね、そもそも継承以前に…という感じだったんですよ ↩︎

  8. 大変申し訳ないです。たぶん今なら投入しないです。若気の至りです。本当にすみません…。ちなみにJenkinsも勝手に投入しました…。Redmine, Subversion, Gitはちゃんと確認とりました。大半の人がわかってなかったと思うけど… ↩︎

  9. 念のため書いておくと、私は前職の全てがダメだったと思いませんし、昨今のネット上の開発至上主義が良いとも思っていません。要するに大事なのはバランスです。 ↩︎