ASP.NET MVC (659ﾚｽ)
ASP.NET MVC http://medaka.5ch.net/test/read.cgi/php/1331013877/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
155: nobodyさん [sage] 2013/10/28(月) 22:36:17.20 ID:??? 試してみろというと逃げる癖してよくもまあ・・・（笑） 何一つ具体的なこと言えない時点でお察しだな http://medaka.5ch.net/test/read.cgi/php/1331013877/155
156: nobodyさん [sage] 2013/10/28(月) 22:55:04.02 ID:??? >>153 ADO.netはORMではないんだから 「Entity Frameworkは一番普及してるORMだ」は事実だろ いまどき生SQLでゴリゴリ書くのは時代遅れ過ぎるんだよ 大昔のADO.net時代のシェアなんてどうでもいい。 日本のITは世界から大きく遅れてるのに、IT後進国の2009年という 大昔の調査のを持ち出してくるあたりが無能の証 Entity Frameworkがなかった時代の調査なぞ論外 >>152 Model Firstとかは分厚いが、Code Firstならそうでもないんじゃない？ Model Firstはだいぶ評判悪かったみたいだよ http://medaka.5ch.net/test/read.cgi/php/1331013877/156
157: nobodyさん [sage] 2013/10/29(火) 01:25:26.20 ID:??? Model Firstが悪いんじゃねーよ。 その実装が糞だってだけだ。 やってればわかるだろ。 しかも、生SQLごりごりとかさ、EFの前までに何段階もあっただろ。 http://medaka.5ch.net/test/read.cgi/php/1331013877/157
158: nobodyさん [sage] 2013/10/29(火) 10:31:38.21 ID:??? EFは、使った人間なら分かるが、ムダにでかくて遅い。 https://code.google.com/p/dapper-dot-net/ 生成するSQLも汚い。 少なくとも初期は使いにくかっただろ。 理想はいいのだが、実装が追いついていない感じ。 最新のバージョンをさらっと触っただけの人はしらんが、俺の認識はこーだ。 DBがそのアプリ、サイトだけで使うものなら ORMで好き勝手にやればいいけど、 他のアプリでも使うテーブルを参照するとかそういうときにトタンに問題が出る。 結局、自作の ADO.NETのラッパー使わざるを得んのは、みんな分かると思うがね。 http://medaka.5ch.net/test/read.cgi/php/1331013877/158
159: 106 [sage] 2013/10/29(火) 13:13:07.99 ID:??? EntityFramework より、Linq to SQL とかのほうが使われているんじゃないの？ (定量的なソースはありませんが) 他にも >>158 の dapper とか dotconnect とか NHibernate とか、ADO.NET直とか、 Javaとちがって .NET界の ORM は、デファクトといったものが無く乱立しているような気がする。 http://medaka.5ch.net/test/read.cgi/php/1331013877/159
160: nobodyさん [sage] 2013/10/29(火) 13:14:24.81 ID:??? 名前欄は間違いです http://medaka.5ch.net/test/read.cgi/php/1331013877/160
161: nobodyさん [sage] 2013/10/29(火) 14:02:36.44 ID:??? ADO.NET データセット、LINQ to SQL、Entity Framework それらの特徴と今後の将来性 http://www.youtube.com/watch?v=uXf_VTPUp8Q http://medaka.5ch.net/test/read.cgi/php/1331013877/161
162: nobodyさん [sage] 2013/10/29(火) 14:16:06.93 ID:??? >>159 古いシステムならLINQ to SQLもあるだろうけど、 新規開発はEFでしょう。MSもEF推してる。 LINQ to SQLはSQL Serverでしか動かないしそれだけでもう駄目だわ あとWindowsのほうが乱立してない MS信仰が強いからMSの技術で代替がない場合を除いて まずMSの技術を使おう、となる JavaはORMはHibernate以外にHibernateの亜種、 JPA、Cayenne、iBatisといろいろある Webフレームワークも乱立していて定番もなくカオス。 Windowsだとほぼ全員がASP.netを使う。 NHibernateもだいぶ人気落ちただろう。 NHibernateのいいところとってEFつくってるし マッピング設定がめんどうなNHibernateを選ぶ理由が見つからない http://medaka.5ch.net/test/read.cgi/php/1331013877/162
163: nobodyさん [sage] 2013/10/29(火) 14:27:37.40 ID:??? >>158 micro ORMはリレーションに対応できないのばっかりじゃないか EFのような高機能なORMと比べてパフォーマンスが速い、 なんて主張はナンセンスだよ 開発生産性を高めるためにORM使っているというのに リレーション対応できないんではメリットの大半が失われてる あとシンプルなリレーションなら、ORMで生成されるSQLはほぼ完ぺきだよ パフォーマンスこだわるなら、正規化ゆるくして複雑なJoinを避けるよう にするのも定石だとおもう http://medaka.5ch.net/test/read.cgi/php/1331013877/163
164: nobodyさん [sage] 2013/10/29(火) 14:31:58.31 ID:??? EF6ってだいぶんパフォーマンス改善されてる感じ？ 4とかはパフォーマンス悪すぎた VSに統合されている(GUIが使える)のは大きなメリットだな http://medaka.5ch.net/test/read.cgi/php/1331013877/164
165: nobodyさん [sage] 2013/10/29(火) 15:21:15.15 ID:??? >>154 おいおいおい、現場で必要なのはDBアクセス手段であって何の技術かなんてどうでもいいんだよ 生SQLやデータセットでは使い辛い、開発し辛い、メンテし辛い、テストし辛い それを解決する手段として模索されてきた一つがORMだろ つまり最初から置き換え狙いでデータセットと競合する それを同列に扱わないって方が意味わからん >>156 EF1はなかったことにしたいんですねとてもよくわかります そして反証は例によって出せない、と・・・（笑） http://medaka.5ch.net/test/read.cgi/php/1331013877/165
166: nobodyさん [sage] 2013/10/29(火) 15:52:44.14 ID:??? >>163 いいえ、遅いことを高機能だからと目をつぶるのはナンセンスです。 開発生産性を高めるためだけにしか使えないとご自分でおっしゃっているの分かりますか？ http://medaka.5ch.net/test/read.cgi/php/1331013877/166
167: nobodyさん [sage] 2013/10/29(火) 17:12:26.56 ID:??? 遅いか速いかとか、そのスピードだけみてもなぁ 使えるかどうかは、必要十分な速度に達してるかどうかが問題なわけで 今のEFは使い物にならないぐらい遅いのか？ http://medaka.5ch.net/test/read.cgi/php/1331013877/167
168: nobodyさん [] 2013/10/29(火) 18:00:14.50 ID:Voe6Fo0l >>164 自分では測ってないけど、速くなってると思う MSのVersion History見るとパフォーマンス改善したという 記述がいくつか見つかる http://msdn.microsoft.com/en-us/data/jj574253 >>165 俺の中ではCode FirstがサポートされたEF4.1以降がEntity Framework それ以前は使ってないし知らん >>158 これわざわざベンチマークとったのになんでバージョンも日付も入れないんだろうね バージョン上がった今となっては参考になるのかすらわからない http://medaka.5ch.net/test/read.cgi/php/1331013877/168
169: nobodyさん [sage] 2013/10/29(火) 18:03:12.42 ID:??? >>161 YouTubeにこんなチャンネルできてたんだ。 エバンジェリストの解説もゆるゆるだなｗ この動画でも、LINQ to SQLはオワコン扱いされてるね http://medaka.5ch.net/test/read.cgi/php/1331013877/169
170: nobodyさん [] 2013/10/29(火) 18:13:35.82 ID:Voe6Fo0l >>166 DataSetとEFでは開発生産性が大違いなんだから EFを使わないという選択肢は可能な限り避けたい。 「高機能ORMを使わずにゴリゴリやる」とか「ストアドプロシージャを使う」 とかいう対策は大きな犠牲を伴う。開発生産性が大幅に低下する。 利用は極力ひかえるべきパフォーマンス対策 パフォーマンスを上げる方法は他にたくさんあるしまずそっちを試せばいい。 メモリを大量に積む SSDにする キャッシュを使う DBのレプリケーションを使う App Serverの台数を増やす これらは時間かけずに対応できる。 「Entity Frameworkを諦める」なんてのは最後の手段だわｗ http://medaka.5ch.net/test/read.cgi/php/1331013877/170
171: nobodyさん [] 2013/10/29(火) 18:19:46.58 ID:Voe6Fo0l >>167 十分に速いよ ありふれたハードで秒間1000クエリ以上こなせる SSD時代になってハードの性能が格段にあがってるから コードでちまちまパフォーマンス改善をやる必要性は低くなってる EF6出てるから使ってみればいい せっかくMSの開発ツール使えるのにEF使わないなんてもったいなさすぎるわ http://medaka.5ch.net/test/read.cgi/php/1331013877/171
172: nobodyさん [sage] 2013/10/29(火) 18:46:09.52 ID:??? EF遅いって、ソシャゲみたいなよほどレスポンスを重要視する業界ならわかる。 それ以外ならたいていインデックス設計、さらにはキャッシュでまず何とかなるでしょ。 http://medaka.5ch.net/test/read.cgi/php/1331013877/172
173: nobodyさん [sage] 2013/10/29(火) 19:38:46.56 ID:??? クエリの組み立てに式木を使う処理である以上、性能面で越えられない壁があるのは事実。 っと言っても、ユーザ数が知れたイントラ用途とかで気になるレベルではないので、 余程性能要件が厳しいものでもなければ使うで良いと思うけど。 それで困るケースではMicro ORMで。 っというか、Expressionsの処理をもっと速くしてください(´・ω・`) http://medaka.5ch.net/test/read.cgi/php/1331013877/173
174: nobodyさん [sage] 2013/10/30(水) 09:50:57.40 ID:??? >>170 使えるなら、使うのに躊躇する理由は無い。 （俺は）使えないという事実を無視して、便利だから、高速化の手法はいろいろあるからといわれても困る。 もったいないって、何がもったいないのかさっぱり分からん。 なんか頭固いなぁ。貴方のの考えや、貴方が便利に使ってるのを否定してるわけでもないのに。 http://medaka.5ch.net/test/read.cgi/php/1331013877/174
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 485 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
1.042s*