ASP.NET MVC

MVCは"model-view-controller"の略で、関心の分離によってテストやメンテナンスのしやすさ、簡潔なコーディングを実現するアーキテクチャです。

・日本語情報

日本マイクロソフト 井上さんのブログ
http://blogs.msdn.com/b/chack/

ASP.NET デベロッパーセンター 技術情報
http://msdn.microsoft.com/ja-jp/asp.net/aa336581

・英語情報

Getting Started with ASP.NET MVC 3
http://www.asp.net/mvc

いろいろありがとうございます。見てみます。

>>231
質問が増えたことと普及度に相関関係があることを証明しろ

というに違いない。

結構前からMSがEFを推奨してるんだから、人気があるのは明白だろ

>>231のstackoverflowでも数字がはっきりでてる。
NuGetのダウンロード数でもEFがぶっちぎり

EF人気にケチつけてくる馬鹿いるようだけど、
そいつは接続すらできなかった無能でアホな>>133だから以後スルーでいい

EF disってる奴は、VS 2008使ってるんじゃね？

自分が駄目だと判断したものを、他人が良いとういのに我慢ができないんでしょう。

>>231
それ全部別人が質問してんだへーすごいねー

>>234
MSが押してたはずのVistaとか8はなかったことにしたいんですねよくわかります
それと試用をも普及に含めちゃう君に乾杯

なんだ、人気にケチつけられてると思って、気に入らないってムキになってる話か。
使ってる人が多いとか、人気があるとかどーでもいい。

異常性を感じるのは俺だけか

>>235
2008だけが使えなかったといいたいのかな？
そんなことなかったぞ。

>>238
人間図星を指されると発狂するもの
それと人気どうこうは心底同意する

つーかスレ違いだと何度言えば分かるのかね発狂してるアホどもは

>>241
お前もだ

>>242
何がお前もかなんかどうでもいいからもう黙れ

>>243
あやべ名前欄間違えた
俺ももう黙る

マッチポンプ

>>234
ん? なんだ俺が接続できなくてべそかいてるとでも思ってたのか?
節穴な奴だなおい（笑）俺は「スキャフォールディングが糞」と言ってるだけだぞ?
>>135の時点でデータコンテキスト/ビュー/コントローラ自作してきっちり動いたわ（笑）
大抵のチュートリアルでスキャフォールディング使ってるのが初見殺しの罠とは流石に思わなくてな
ま、ここんとこM$の出してくるもんは開発系に限ってはいい感じばっかだから油断してた俺が悪いんだがね
それから信じる信じないは勝手だが、俺は今日ここ初めてのカキコだ
まあ信じないだろうけどな自分のお花畑が全てっぽいからお前

>>203
どうやってDB作ってるって聞いてるんじゃなくて、どうやって設計してるって聞いてるんだが
モデルからDB作るんであれば、モデルを設計する段階でDBの実テーブル意識してるのか？
ORMって結局モデルの(永続化)データストアとしてRDBを使ってるだけじゃないのかと言う気がするんだが
それって本末転倒じゃないのか
コードファーストとか特にその傾向が強い気がするんだが

Entity Frameworkもそうだけど、更新系の処理がオブジェクト値を書き換えてSaveChanges()っていうのがなー。
いっそ式木によるSQLビルダーに徹してくれた方が適用範囲も広がるのに。
まあ、式木からUPDATEやDELETEを作り語ったら、拡張ライブラリを入れればいいんだけど。

>>247
やぱりおまえどうしようもなく馬鹿だな
>>201でEFについて質問してるんだから答えは的確

＞モデルを設計する段階でDBの実テーブル意識してるのか？

当たり前だろアホｗｗ
頭の中でデータベースの論理モデルの設計もできてない段階で
ORMのマッピング設定ができるわけがないだろｗｗ

パフォーマンスと正規化原則のバランスとりながら
どこまで正規化するか、JOINはどうするか、いろいろ考えて
最終的なテーブル設計をイメージしながら
そのテーブルに対応するmodelをcode firstで書いていくんだろ

スキーマ設計する前にModelやORMのコード書けると思ってる所がアホすぎる

ORM使うならスキーマが前提だけど、コードファーストならそうでもないのでは

>>250
テーブル設計・設定と、Object(model)のコーディングを同時にできるってだけだ

基本的にModelのコードがそのままDBのColumnになるんだから、
頭の中でテーブルの設計ができていないと書きようがないだろ

ORMはDB設計を不要にしたり自動化するツールではない

>>251
> ORMはDB設計を不要にしたり自動化するツールではない
いやだからORMならスキーマが前提だって書いてるじゃん。

> 基本的にModelのコードがそのままDBのColumnになるんだから、
> 頭の中でテーブルの設計ができていないと書きようがないだろ
最悪（？）DBなしでも動くんだから、テーブル設計ありきという概念じゃないでしょ。

>>252
どういう意味？EF使うのにDBなしという意味は？

>>253
コード･ファーストの特徴の一つはModelをPOCOで記述できること。
それ故、永続化レイヤーとの結合をシステム全体として緩やかなものにできる。
ビジネスロジック層も、大部分を永続化レイヤーから切り離すことができる。
ユニットテストも、データベースなしで実行できる部分が増える。

>>254
それEFでなくても出来るじゃん
それこそDataSetの昔から
ほとんどのケースで意味ないからしてないだけで
CodeFirstのメリットなんて設計試作が簡単ってくらい
DB設計は専門に任せる中規模以上の開発形態じゃほぼ意味を成さない

>>255
> ほとんどのケースで意味ないからしてないだけで
そんなことない。
他言語でも永続化部分をインジェクションするのは良くある手法。

> DB設計は専門に任せる中規模以上の開発形態じゃほぼ意味を成さない
EFのコード・ファーストは、永続化レイヤーと切り離せるのがメリット（というかそうするのが主目的か？）なので、
それに意味をなさないと思うのならコード･ファーストは無意味だね。

>>255
> DB設計は専門に任せる中規模以上の開発形態じゃほぼ意味を成さない

なんで？仮に先にDBスキーマありきだとしても、ModelをPOCOで書けるのはメリットあるだろ。

>>255
「永続性非依存」でググってみてくれ。

>>256
実際にEFあんまりさわってないからイメージできないんだが

コードファーストが永続化レイヤー（ここではDBだわな）と切り離せるのがメリットなのか？
コードファーストってコードによりDB(テーブル)作るんじゃないのか？

本来のORMではテーブル定義やクラス定義を変更しても、マッピングを変更することにより
相手にその変更の影響を受けなくする事が出来るだろうけど
コードファーストでやってモデル定義やテーブル定義変更して、影響を抑えられるの？
それが出来ないなら、永続化レイヤーとの切り離しとは何を意味してるの？

>>259
> それが出来ないなら、永続化レイヤーとの切り離しとは何を意味してるの？

Model層以上の永続化処理との切り離し。

>>260
もうちょい詳しく言ってくれんと分からんが
永続化処理までフレームワークに任せる事により、永続化されてる所を意識しないってことか？
それって永続化レイヤーを切り離してるんじゃなくて、永続化レイヤーまで内包して
一体化してるんじゃないのか？

>>261
悪いんだけど、まず「永続化非依存」でググっていくつか記事を読んでくれないか。

>>262
コードファーストで永続化非依存を実現する記事を紹介してくれ
日本語じゃないとちゃんと理解できないからなるべく日本語のやつを

永続化非依存の人に聞きたいんだが
あるシステムを開発して、そのDBをコードファーストで作成したとする
そのDBを別の新システムからも使うようにしたい
そのために、今のテーブルにカラムを追加したい

元のシステムのコードは変更するべきか否か？
コードファーストではDBとコードは（将来にわたって）一致すべきか？

変更しないなら、その時点でコードからのDB作成という概念が外れるわけだが
永続化レイヤーに依存しないなら、当然変更すべき理由はないわな

一般論じゃなくて私見でも良いので答えてくれ

Code First dis
http://ogacha.wordpress.com/tag/ado-net-entity-framework/

階層がたくさんある時にいちいちMapRoute書くのクソ面倒なんですが何か簡単な方法ありませんか

ありません

>>267
ありがとうございました糞ですね

monoでMVC4動かない、.Net framework 4.5に一部対応したって書いてるけどASP.NET 4.5は非対応
っつーかMVC4〜5ってEntity framework含めて4.5依存多すぎて実質MVC3%2b.Net framework 4.0でしか使えないんじゃないのか？w

>>264
そもそもコードファーストなんてのが頭おかしいって分かるでしょ?
アプリケーション専用のデータ置き場程度に使うならいいけど、様々なアプリから
アクセスされるであろうシステムのバックエンドに使うなんてとんでもない。
これは非常にスジの悪い技術だよ。

>>270
単なるデータストアとして使うぐらいなら良いんじゃないの、ってのは俺もそう思うんだが

コードファーストが
>永続化レイヤーとの結合をシステム全体として緩やかなものにできる
>永続化レイヤーと切り離せるのがメリット
と主張する人がいるんですが

>>271
端的に言えば
コードファーストなんてのはDDLをC#で置き換えただけで
本質的にモデルファーストと何も変わってない。

永続化非依存の話については
データモデルをPOCOで扱うなんてのは別にモデルファーストでもできることで
コードファーストとはまったく何の関係もない。そんな主張はバカ。

年明けからASP.NET MVCの爆発炎上している案件に突っ込まれそうなんですが、
今のうちに勉強しておいたほうがいいことはありますか？
とりあえずVS2013 Express for Webはインストールしてみまみた。

あんたが元々何の仕事してたかによるが
気をつけることとしては、EFは「使わない」こと
上でやたら押してる阿呆がいるが耳を貸してはいけない
EF6になっても仕様バグだらけだ
そしてASP.NET MVCはEFなんぞ使わなくとも全機能使用できるし、
EFさえ排除してしまえば分かりにくいところはほとんどない
Model関連で戸惑うかもしれないが、EF部分をLINQにでも読みかえれば概ねおk
サンプル読み替えとかでわからないことがあったら聞いてくれ

>>274
> EF部分をLINQにでも読みかえれば概ねおk

既に炎上してる位進んでいるプロジェクトで、EFを使わないとか言い出せるもんかな。

>>274
仕様バグって何のこと言ってるんだろう
あんたが使い方わかってないだけじゃないの

>>275
274はEFもLINQ使ってるのも知らないようだね

>>277
いいからそういうの

>>276
もう「自分表示回りしか知らないんで」つってDB回りから逃げるしかなかろうな
どうせ炎上してんのそこ(EF)だろうけど
MVCで他にハマりどころなんてほぼないし
強いて言うならDisplayForとかをカスタマイズしようとして余計なコスト掛かってるくらい?

>>279
フレームワークにハマりどころがなくたって炎上するプロジェクトなんていくらでもあるし
むしろそっちのほうが多いだろw

>>280
さてそうかな?
大抵のフレームワークにはバッドノウハウって奴があって、炎上案件は大体その地雷踏み抜いた奴だ
一昔前はともかく、今時は仕様ちゃぶ台返し食らったって炎上まで行かないよ
お客さんもわかってくれてるからね昔と違って

EFがダメなのは俺も言い出した口なのであれだが、
お前はあまりに粘着しすぎてキモイのと、
そもそも、あれで炎上とか、変。

結論 : SQLは手書きしろ。ORMは死ね。

>>282
誰だと思い込んでるか知らんがまず日本語が変だな君

粘着してる自覚があったとは。

>>247
仕様バグと言う糞トンチンカンな言葉を使っている時点で、
どういうレベルの場所にいるかだいたい察するよ。

言うなら設計ミスだろ。

安価ミスにも気づかないとは程度が知れるな
ま、レベルの場所とかいう俺様用語使ってる時点で同類だは

>>1
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
http://toro.2ch.net/test/read.cgi/tech/1393660194/30

ASP.NET MVC の Controller クラスについて質問があります。
Controller クラスは、リクエストがあるたびに new されるのでしょうか?
それともJava Servlet の Servlet クラスのように、1つしかインスタンスが作られず、マルチスレッド間で全てのインスタンスが共有されるのでしょうか?

前者であれば、Controller クラスにフィールド(プロパティ)を作成しても、同時に複数のリクエストがあっても問題ないですよね。

ASP.NET MVC 3縛りの環境で使えるASP.NET Identityみたいなライブラリありませんか？

Microsoft ASP.NET MVC Security Update MS14-059 (KB2990942)
http://www.microsoft.com/en-us/download/details.aspx?id=44533

Oracle10gでEntityFrameworkを使用する術はありますか？

>>292
接続クライアントに最新のODP.NET入れてVS2010以降ならいけるんじゃないかな
付属のクライアントだと無理

ODP.NETだけバージョンアップできるんですね。知りませんでした。ありがとうございました。

MVCでEntiryFramework使わないパターンって、Oracle接続してSQL発行する処理をモデルに作れば良いんですか？

そゆ例がどこにもないけど、なんかダメなのかなー

>>295
別に問題ないでー
モデルの存在意義がそもそもそういうものだ

ありがとうございます
EntityFrameworkなかなかめんどそうなので、普通にSqL発行します

>>297
micro ormの類いを使うといいんじゃないかな。
dapperとか。

>>298
恥ずかしながら初耳のものでググりました。
複数システムでテーブル共有する状況でも使えていいですねこれ

MONOいらなくなるの？
http://www.publickey1.jp/blog/14/jitnet_core_rutimenet_framework.html

>>300
monoと協力するとも言われているし、直接使うことはなくなるかもしれないけど、
恩恵は受けるんだろうね。

あと、ライセンスがAPLになるおかげでMS純正のコードをmonoがそのまま利用できるから
monoは独自にパワーアップできるとも取れる。

>>299
まともにADO.NETを使うとか
俺俺フレームワークでラップするとかは今どきNGだと思うので、
やはり薄めのORMをかませるといいと思うよ。

EF使ってても複雑なクエリは結局SQL書くし
数年前の自分もdapperあたりで手を打っておけばよかったと・・・。

EF7は薄くする話らしいけど、どうなるやら。

.NETのOpen Source化で
ASP.NETがLinux serverでも使えるようになるなんて嬉しいね
前からMonoはあったけど情報少なくて使い方がよくわからなかった。

>300-301
http://www.itmedia.co.jp/news/articles/1411/13/news052.html

Microsoft純正でLinux/Mac用.net runtimeが出たなら
Mono使う人はほとんどいなくなるんじゃないの

>>302
dapperってリレーションは使えるの？

>>303
> >>302 dapperってリレーションは使えるの？
テーブル間のリレーションを解決させるという意味なら、
もちろん不可能。microじゃなくなっちゃうしｗ

クエリリザルト→オブジェクト変換のフレームワークと捉えれば良いかなと。
ActiveRecordパターンとは違うよ。

StackExchange/dapper-dot-net · GitHub
https://github.com/StackExchange/dapper-dot-net

それって型付きデータセットとどう違うの？

ん？どの辺がDataSetっぽいの？
オブジェクト側はもっとシンプルなんだが・・。

Fluent NHibernateをおすすめしてみる
マッピングがクソ面倒だがDevartのツール使えばすべて自動でやってくれる
monoでも安定して動く

初心者の質問で恐縮ですがよろしくお願いします。

いま、DBのデータを画面に表示する勉強をしています。
ADO.NETで取得した結果を予め用意したクラスに代入して、それをコントローラからビューに渡しています。ビューでは「@モデル クラス」を記述し、DisplayForなどで画面に表示はできました。
が、複数テーブルのデータを表示する方法が分かりません。

コントローラで持ってる複数のSQL結果をビューに渡すにはどうすればいいのですか？

>>308
SQLの習熟度はどんなもの？結合(join)って分かるかな・・？

> コントローラで持ってる複数のSQL結果をビューに渡すにはどうすればいいのですか？
これの意味は
・2テーブルを、それぞれ分けて2個の表に表示したい
・結合して2テーブルの情報を1個の表に表示したい
どっちでしょうか。

>>309
アプリ開発経験はないのですが、SQLは分かります。

教えて頂きたいのは前者です。
複数のSQLを発行した場合の、ビューへの渡し方が分かりません。

>>310
なら話は早いですね。

まずは単純にBigViewModelな方法でいいんじゃないでしょうか。
とりあえず表示できるようにはなるかと。
http://stackoverflow.com/questions/4764011/multiple-models-in-a-view

その後、想像するにControllerでSQL発行などやっているようであれば
Model側に分離すると良いです。
（MVCらしくしたければ）
分離の仕方はいろいろあるので、趣味レベルならこだわりすぎないことですが。
http://blog.shibayan.jp/entry/20111231/1325304627

「ASP.NET MVC 5実践プログラミング」とか一冊あると捗るんじゃないかなー

>>311
登録画面で複数のドロップダウンに複数のリソーステーブルの値を設定したかったので、解決です。
ありがとうございました。

MVCの分離も気をつけます。
また、本も買ってみようと思います。

Linux上で実行できるようになったと聞いて飛んできました
Google App EngineのDocker対応で、ASP.NET MVCも使えるようになるのかな？

ついでにMS純正IDEもオープンソースにして（Eclipseみたいに）
LinuxやMac OS Xで動くようにすりゃいいのにな
Windowsの糞フォントレンダラで描画されたソースコードあんまり見たくないんだよね…

linqの
item.where(i => i==2)
のような表記は理解できますが、
mvcの
foreach(var item in Model)｛
@Html.Displayfor(modelitem => item.ID)
｝

が分かりません。
item=>item.IDじゃないのは何故ですか？

>>315
@Html.Displayfor(() => item.ID)
・・・にしたらどうなる？

>>316
エラーとなります

>>315
ttp://forums.asp.net/t/1923928.aspx?in+Html+DisplayFor+modelItem+item+Genre+what+is+modelItem+

>>318
「初めの頃みんなつまづくとこだよ！
modelitemは使ってないからきにすんな。foreachのとこでItemがあるから、Item.IDでつかえるんぜ！」

「んー、ちょっとまだ理解できてない。まぁおれまだC#の勉強終わってないし、終わった頃にはわかってるかもね」

MVCわかりません。

{[ID][名前][所属ID]}
と
{[所属ID][所属名]}
テーブルがあったとして

{[ID][名前][所属名]}
を画面に表示したいときは

class test
{
int ID;
string name;
string section;
}

みたいなクラスにSQLの結果をマッピングしなさいってことなんですか？

ちがいます

>>321
ちがいますか(´･_･`)

どこが間違っていますか？

強いて言うなら、あなたがASP.NET MVCなんてやろうとしていることが間違いです。

>>322
かなり荒いけど合ってると思う・・。

>>323
Mの役目は、DB→クラスのマッピングかと思ってますが、間違ってますか？(´･_･`)

>>324
荒いけどあってますか^ ^
ADO.NET→クラスへのマッピングだけで疲れちゃいそう

EFは使っちゃダメなん？

>>325
ORMを活用すればいいんじゃないかと。
勉強が目的ならそのままでも構わないけど。

>>325
>Mの役目は、DB→クラスのマッピング
マッピングそのものはモデルの本来の役目じゃないよ
元データがDBにあればマッピングする事によって結果としてデータを用意できるってだけで
あくまでもビューのためにデータを用意するのがモデルの役目
マッピングはそのための手段
DBからクラスを生成するのは、そのためのフレームワークがあるからそれ使うのが一般的

>>326>>327
既存のDBという事と、ORM未経験ということもあり、EFは避けてました(._.)

>>328
分かりやすいご説明ありがとうございます。まずEFを試した方が良さげですね(._.)

micro ORMでもいいんじゃないかと。
どうせ既にSQL書いちゃってあるんでしょう？

>>330
ありがとうございます。
マイクロORMも他もそうなのですがMVC関連 の情報が少ないですね。みなさん何処で知識を得てますか？

実践プログラミングは買いました。