トップ回答者
Entity FrameworkとTableAdapterについて

質問
-
マイクロソフトがデータソースを扱う技術としてTableAdapter(DataSet)からEntity Frameworkへ移行した理由についてご存じであれば教えてください。
.NET Frameworkではデータソースを扱う技術としてTableAdapter(DataSet)が採用されていましたが、Entity Framework登場以降はマイクロソフトはEntityFrameworkを推奨する方向にシフトしています。
TableAdapter(DataSet)はデータベースの内容をデータセットに構築し、データセットにあるデータをAdapterを介して扱う技術でした。ビジュアルエディタの問題で表示が遅かったりやスキーマを変更した場合に同期がとれないといった問題は抱えていたものの、考え自体は私は良いアイデアだと思っています。マイクロソフトはこの技術をより堅牢にしていく方向ではなく、Entity Frameworkという新しい方向でデータソースを扱う方向にかじをきりました。これはなぜなのでしょか?
一つだけ思い浮かんだのはORマッピングの考え方をデータセットという独自路線ではなく、RailsやHibernateに合わせることでJavaやrubyしかやっていない技術者を取り込もうという戦略があったのかなというぐらいです。
もし、データセットによるORマッピングにはなんらかの問題があり、それゆえ概念モデルを利用したORマッピングであるEntity Frameworkに移行したという具体的な理由があれば知りたいと思っています。みなさんのお考えを教えて頂ければ幸いです。
回答
-
初めにお断りしておきますが、以下、一個人のあくまで感想です。
まず、Entity Frameworkへ移行したというわけでは無いと思います。VS2013でもDataSet、TableAdapter等は普通に作成できます。かつて、TableAdapterが出てきた時、DataAdapterはデフォルトでは表示すらされなくなりました。
さて、本題に戻りますが、Entity Frameworkが出て来た背景として、一番大きいと感じているのは、開発者がTransact-SQLを学習しなくても良いという理由なんじゃないかと思います。Entity Frameworkが無ければ、データベースを扱うアプリケーション開発者は、Transact-SQLの知識に加えて、ADO.NETの知識が必要になります。DataSet、DataTable、DataAdapter、DataCommand、DataReader・・・、その他のクラスについて、その動作をきちんと把握する必要があります。これは決してハードルが低いものでは無いでしょう。
このハードルを下げるために、歴史的にはTableAdapterが登場し、DataAdapter、DataCommand等が隠ぺいされました。
それでも尚、Transact-SQLの知識は必要です。ましてや、エンティティという概念も持ち込もうとすると、決して不可能ではありませんが、それを実現するためにはこれらADO.NETに精通している必要があります。
新規の開発者が容易に参入できるとは・・・・・言い切れません。そのような背景から、Entity Frameworkが生まれてきた割合が高いのではないかと思います。ですから、最初はデータベースファースト、モデルファーストが先行し、後にコードファーストが追加されたのも同じ背景によるのだと思います。
ちなみに少し話が逸れますが、LocalDBというのも同じような背景で生まれてきたものなのでしょう。データベースアプリを開発する時に、SQL Serverのセットアップや管理まで学習するのではなく、簡単にローカルな自分専用のSQL Serverが準備できるのであれば、データベースアプリの開発の敷居はぐっと下がります。ただ、私としては、本当はTransact-SQLが書けるようになって欲しいと思います。SQLに精通していれば、SQL一文で済むことを、クライアントコードで複雑な処理をしなければならなくなることがあります。特に、他と差の付く機能を実装する場合には、この差は大きいと感じます。一般的なCRUDだけではなく、ユーザーからこの機能が欲しいと言われた時に、それを少ない工数でエレガントに実装できる力の差です。
本来、このような高度な機能を実装するにはデータベースの良い設計が実質的に不可欠です。その前に、まず、SQL文が頭に浮かぶようになることです。さらに、ADO.NETに精通していれば、それらSQLと協力して、もっとエレガントなことが可能になります。
と、ここまで書きましたが、実際、新規で開発を始める開発者にここまで求めるのは酷だと思います。C#もバージョンアップを経て、多くの機能を実装してきました。もちろん、非同期処理など、簡単に書けるようになった部分もあります。しかし、それでも学習すべき量は増えているでしょう。それに加えてADO.NET、Transact-SQLまでも・・・とは、なかなか現実性が無いのかもしれません。
私は上で書いた方法で開発しますが、それは10数年もの月日の流れで得てきたものです。ADO.NETだけでも約700ページの本を読んでいますが、それも全体の中ではごく一部です。ですから、Entity Frameworkを使って開発の敷居を下げることは良いことだと思いますし、もし、私の周りに新人がいたら、そうしているかもしれません。ただ、やはり、そこで満足しないで、言い方は悪いかもしれませんが、いずれはSQLフェチ、ADO.NETフェチになって欲しいと思います。
構造化プログラミングからオブジェクト指向に移行したのではなく、オブジェクト指向の中にも構造化プログラミングの考え方は生きています。同様に、Entity Framworkに移行したのではなく、TableAdapterも使うべきところでは使えるように技量を高めって行ってほしいと思います。#そういえばメモリーの話が出ていましたが、Entity Frameworkのlazy-loadingの場合と比較されているのかな?と思いました。私は主にTableAdapterを使いますが、人が読めないほどの情報を読んできても仕方ない派ですので、一度に多くを読み込ませることはありません。Entity Frameworkでもeager-loadingすれば、TableAdapterと状況は同じになるはずです。
#先に指摘されていましたが、質問というよりディスカッションに近いように感じられますが、いかがでしょうか? その場合には、このスレッドを質問からディスカッションに変更できますので、ご検討下さい。
(追記)
ディスカッションに変更するというのは、このスレッドのタイトルの下にある「種類の変更」より、「スレッドの種類」を「全般的な情報交換」に変更することです。
★良い回答には回答済みマークを付けよう! MVP - .NET http://d.hatena.ne.jp/trapemiya/
- 編集済み trapemiyaModerator 2015年3月16日 14:28 追記
- 回答としてマーク ryu-suke 2015年3月16日 15:37
すべての返信
-
質問ではなくディスカッションのような気もします。というわけで個人的な見解を。
TableAdapterはデータベースからテーブル行を一式 .NETメモリ空間に読み込み、C#メモリ空間で処理を行います。読み込みには多大なコストを要しますし、.NETメモリ空間に読み込み切れない量のデータは扱えません。そして本来データを扱うべきデータベースエンジンは単なるストレージとしてしか見なされなくなります。
ところでメモリ上で処理を行うのであれば何もDataSetを使う必要はなく通常の.NETオブジェクトで構わないという話もあります。対してEntity Frameworkではクエリを実行時に動的に組み立て、そのクエリをデータベースエンジン上で実行します。その上で実行結果を.NETメモリ空間に読み込みます。ですので、途中、膨大なデータを扱ったとしても結果サイズが.NETメモリ空間に収まれば問題ありません。またデータベースエンジンも本分を全うします。
加えてLinq to Objectsも用意されているため、LINQを用いることで.NETのオブジェクト処理とデータベースエンジン上での実行をある程度共通化できます。このような違いがあると思います。
-
雑談レベルのレスしかできませんが、そんな難しい問題じゃないと思います。
単純に「より便利にしよう」「流行も取り入れよう」で今の形になったのではないでしょうか?
Entity Framework も Ver.6 以降はだいぶいいですよ。
TableAdapter+DataSet も 旧ADOのRecodesetに比べると便利でしたが、
Entity Framework も TableAdapter+DataSet から大幅に進歩してきてます。
私はもっぱら Database First で使ってますけど、自動生成されたEntityモデルは感動ものです。 -
書いたことの半分くらいしか伝わってない気がしたので補足しますと、
データベースエンジンは大量のデータを効率よく処理する方法を知っています。インデックス等、データの格納方法も工夫されています。統計情報も参考にして複数のアルゴリズムから選択して処理を実行します。
これに対して.NETでは処理をプログラマが書いた通りに実行するのみです。
ですので、単にSUM()するだけでも所要時間には大きな差があると考えています。その上で、Entity Frameworkではデータベースエンジンに任意の指示を出せるわけです。DataSetからEntity Frameworkに移行したわけではなく、まったく別の領域を扱っていると思います。
-
初めにお断りしておきますが、以下、一個人のあくまで感想です。
まず、Entity Frameworkへ移行したというわけでは無いと思います。VS2013でもDataSet、TableAdapter等は普通に作成できます。かつて、TableAdapterが出てきた時、DataAdapterはデフォルトでは表示すらされなくなりました。
さて、本題に戻りますが、Entity Frameworkが出て来た背景として、一番大きいと感じているのは、開発者がTransact-SQLを学習しなくても良いという理由なんじゃないかと思います。Entity Frameworkが無ければ、データベースを扱うアプリケーション開発者は、Transact-SQLの知識に加えて、ADO.NETの知識が必要になります。DataSet、DataTable、DataAdapter、DataCommand、DataReader・・・、その他のクラスについて、その動作をきちんと把握する必要があります。これは決してハードルが低いものでは無いでしょう。
このハードルを下げるために、歴史的にはTableAdapterが登場し、DataAdapter、DataCommand等が隠ぺいされました。
それでも尚、Transact-SQLの知識は必要です。ましてや、エンティティという概念も持ち込もうとすると、決して不可能ではありませんが、それを実現するためにはこれらADO.NETに精通している必要があります。
新規の開発者が容易に参入できるとは・・・・・言い切れません。そのような背景から、Entity Frameworkが生まれてきた割合が高いのではないかと思います。ですから、最初はデータベースファースト、モデルファーストが先行し、後にコードファーストが追加されたのも同じ背景によるのだと思います。
ちなみに少し話が逸れますが、LocalDBというのも同じような背景で生まれてきたものなのでしょう。データベースアプリを開発する時に、SQL Serverのセットアップや管理まで学習するのではなく、簡単にローカルな自分専用のSQL Serverが準備できるのであれば、データベースアプリの開発の敷居はぐっと下がります。ただ、私としては、本当はTransact-SQLが書けるようになって欲しいと思います。SQLに精通していれば、SQL一文で済むことを、クライアントコードで複雑な処理をしなければならなくなることがあります。特に、他と差の付く機能を実装する場合には、この差は大きいと感じます。一般的なCRUDだけではなく、ユーザーからこの機能が欲しいと言われた時に、それを少ない工数でエレガントに実装できる力の差です。
本来、このような高度な機能を実装するにはデータベースの良い設計が実質的に不可欠です。その前に、まず、SQL文が頭に浮かぶようになることです。さらに、ADO.NETに精通していれば、それらSQLと協力して、もっとエレガントなことが可能になります。
と、ここまで書きましたが、実際、新規で開発を始める開発者にここまで求めるのは酷だと思います。C#もバージョンアップを経て、多くの機能を実装してきました。もちろん、非同期処理など、簡単に書けるようになった部分もあります。しかし、それでも学習すべき量は増えているでしょう。それに加えてADO.NET、Transact-SQLまでも・・・とは、なかなか現実性が無いのかもしれません。
私は上で書いた方法で開発しますが、それは10数年もの月日の流れで得てきたものです。ADO.NETだけでも約700ページの本を読んでいますが、それも全体の中ではごく一部です。ですから、Entity Frameworkを使って開発の敷居を下げることは良いことだと思いますし、もし、私の周りに新人がいたら、そうしているかもしれません。ただ、やはり、そこで満足しないで、言い方は悪いかもしれませんが、いずれはSQLフェチ、ADO.NETフェチになって欲しいと思います。
構造化プログラミングからオブジェクト指向に移行したのではなく、オブジェクト指向の中にも構造化プログラミングの考え方は生きています。同様に、Entity Framworkに移行したのではなく、TableAdapterも使うべきところでは使えるように技量を高めって行ってほしいと思います。#そういえばメモリーの話が出ていましたが、Entity Frameworkのlazy-loadingの場合と比較されているのかな?と思いました。私は主にTableAdapterを使いますが、人が読めないほどの情報を読んできても仕方ない派ですので、一度に多くを読み込ませることはありません。Entity Frameworkでもeager-loadingすれば、TableAdapterと状況は同じになるはずです。
#先に指摘されていましたが、質問というよりディスカッションに近いように感じられますが、いかがでしょうか? その場合には、このスレッドを質問からディスカッションに変更できますので、ご検討下さい。
(追記)
ディスカッションに変更するというのは、このスレッドのタイトルの下にある「種類の変更」より、「スレッドの種類」を「全般的な情報交換」に変更することです。
★良い回答には回答済みマークを付けよう! MVP - .NET http://d.hatena.ne.jp/trapemiya/
- 編集済み trapemiyaModerator 2015年3月16日 14:28 追記
- 回答としてマーク ryu-suke 2015年3月16日 15:37
-
補足して頂いてありがとうございます!
確かに私がDataSetのデータを直接扱って、検索や集計を行っても洗練されたデータベースのエンジンの実装にパフォーマンス面でおよぼないと思います。EntityFrameWorkではデータベースエンジンに検索や集計などの処理を全て依頼できるのでDataSetを直接操作するよりパフォーマンス面で有利だと思います。
DataSetとEntityFrameworkで観たとき、たしかに扱う領域はメモリとデータベースでまったく異なっているのですが、TableAdapterとEntityFrameworkで観たときは同じレベルの話になるというように考えています。どちらもデータソースに対する処理に対する話ですので。とはいえ、このように色々とご指摘を頂くことで自分の理解も深まっており、大変感謝しております!
お忙しいところ、ご返信いただき本当にありがとうございました!
-
ご返信ありがとうございます!
>#先に指摘されていましたが、質問というよりディスカッションに近いように感じられますが、いかがでしょうか? その場合には、このスレッドを質問からディスカッションに変更できますので、ご検討下さい。
ありがとうございます!ご指摘を受けて種類の変更を行おうとしたのですが、種類を変えるとこれまでの回答が全部消えるよというメッセージが。。。せっかくお答え頂いたのに消えるのは嫌すぎると思ってまだ変えていないですが、変えても回答は残るものなのでしょうか?
全然、関係のない質問をしてしまってすいません。
学習コストを少なくする、また参入の障壁を下げるという考え、素晴らしいですね!すごい納得感があります。確かに利用者に詳細を隠ぺいすることで、利用者は概念と使い方だけわかれば内部の詳細をしらずともつかえちゃいますよね。まさにオブジェクト指向と同じ考え方です。EntityFrameworkは確かにSQL
をしらずともメソッド呼び出しだけでデータアクセスが可能になるので使う側はとっても楽ですよね!とはいえ、ここにジレンマがあってSQLや内部の挙動をしらないことでトラブルシューティングができなかったり、パフォーマンスの最適化ができないという問題もでてくるのでしょうが。。。とはいえ、やることを簡単にして参入障壁を低くするというのはとても大事な事だと思います。非常に参考になる意見を頂いてどうもありがとうございます!
追記--------
eager-loadingおよびlazy-loadingに関する意見を頂いてありがとうございます。eager-loadingというのは初めて聞く単語だったので調べてみたところ、N+1問題というものがあることを初めて知りました!
データアクセスの話は本当色々あって奥が深いです。
- 編集済み ryu-suke 2015年3月17日 2:49
-
ありがとうございます!ご指摘を受けて種類の変更を行おうとしたのですが、種類を変えるとこれまでの回答が全部消えるよというメッセージが。。。せっかくお答え頂いたのに消えるのは嫌すぎると思ってまだ変えていないですが、変えても回答は残るものなのでしょうか?
経験上、「種類の変更」によって書き込みが消えたことは無かったのですが、改めて確認してみました。
その結果、消えたのは回答ではなく、「回答としてマーク」や「回答の候補」でした。
考えてみれば当たり前で、「種類の変更」を「全般的な情報交換」に変更した場合、回答としてマーク」や「回答の候補」が残っているのはおかしなことですから、これらが消えることはもっとものことだと思います。よって、書き込み自体が削除されてしまうわけではありません。なお、今回は「全般的な情報交換」という形には結果的になりませんでしたので、このまま「種類の変更」は「質問」のままで良いように思います。
★良い回答には回答済みマークを付けよう! MVP - .NET http://d.hatena.ne.jp/trapemiya/
-
> とはいえ、ここにジレンマがあってSQLや内部の挙動をしらないことでトラブルシューティングができなかったり、パフォーマンスの最適化ができないという問題もでてくるのでしょうが。。。
ちょっと本題から離れてしまい申し訳ありませんが、ここだけ反応しました。ここ数日、「理論から学ぶデータベース実践入門」 という本を読んでます。著者は奥野幹也さんという方で、MySQL がオラクルに吸収される以前からMySQLのサポートに従事されてます。MySQLユーザー内では非常に有名な方で、ブログでもためになる記事を数多く公開されています。
この本では、RDBの基であるリレーショナルモデルにつき、集合論や論理学など数学的理論に裏付けられた非常に強力なモデルであり、RDB はリレーショナルを実践して初めて真価を発揮すると、集合論や論理学の解説を用いてかなり深部に踏み込みながら力説してます。
考えてみたら、私が開発の真似事を始めてからもう十数年経ちますが、その間、開発言語やツールの流行り廃りがあり言語仕様が大きく変わることがあっても、SQLの仕様に大変更があったという話は聞きませんし、今後もRDBの基本仕様は変わらないと思います。何故RDB や SQL はそんなに普遍的なのか・・・この本を読んで、数学的理論の強力な裏付けに基づいているという事実にハッとしました。
恥ずかしながら私もRDBについてはそれほど勉強しておらず、リレーショナルということをただ漠然と捉えていたのですが、集合論・命題論理・述語論理・従属性etc・・・様々な数学的概念と格闘しつつ読み進めるうち、ある結論に達しつつあります。
・・・もしかして、リレーショナルモデルって美しい?
もちろんRDBはリレーショナルモデルだけで設計されておらず、リレーショナルモデルの概念だけで現実の諸問題を解決できるほど甘くはありませんが、RDBの根底にある理論を知ると知らざるでは、アプリケーションの品質が大きく変わってくると思いました。
あとついでに数学・・・ちょっと本格的に学び直したくなってきちゃいましたw
筆者も異論出るのは承知の上、この本により議論が発生するのを望んでおられるようです。暇(と予算)があったら是非一読お勧めします。
ぜひ 「フォーラムでご質問頂くにあたっての注意点」 もご覧ください https://social.msdn.microsoft.com/Forums/ja-JP/ca9ecfb7-4407-4fcb-b8bd-207d68257e68?forum=announceja
- 編集済み ひらぽん 2015年3月17日 2:03 多少校正し直した
-
ご返信頂いてありがとうございました!
確かにSQLの基本は全然変わってないですよね!
プログラムのif文とかfor文のレベルで一度学べば長く使える技術だと思います。そして確かにSQLって使えるのは使えるのですが、理論から体系立てて学んだ記憶はほとんどありませんでした。リレーショナルに関する土台をしっかりもつことでデータベースに関する応用的な様々な課題に対処できると思いますのでご提案頂いた書籍は購入して土日に読んでみたいと思います!私もリレーショナルモデルを美しいと思えるまでリレーショナルの世界を理解してみたいです!
RDBに関するとても参考になる意見と書籍をご提示頂き、ありがとうございました!