【質問】ASP.NETスレ Part5【議論】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2009/01/23(金) 09:46:51ID:???Part1 - 【質問】 ASP.NETスレ 【議論】
http://pc5.2ch.net/php/kako/1040/10406/1040698263.html
【質問】ASP.NETスレ Part2【議論】
http://pc8.2ch.net/test/read.cgi/php/1111480331/
【質問】ASP.NETスレ Part3【議論】
http://pc11.2ch.net/test/read.cgi/php/1160355849/
【質問】ASP.NETスレ Part4【議論】
http://pc11.2ch.net/test/read.cgi/php/1184683786/ （dat落ち？）
あんまり需要ないのかもしれませんが。。。
0653627
2009/07/23(木) 17:25:10ID:???> 同じDLLをASPとコンソールの二つからみてるわけだから同じじゃん
サーバーサイドだけならdeployする手間が、普通のクライアントアプリとは違うので
>>649の「それだと、仮にクライアントアプリだと、修正されるたびに、すべてのPCにデプロイする必要があるから面倒」
という問題は無いかな、と思いました。
> 異なるバージョンのDLLで稼働してるのが気持ち悪くない人なら別にいいけど。
この部分がいまひとつ理解できていないのですが、私の構成は次のようになっています。
コンソールプロジェクト = DBの掃除を行なうコードを書いたプロジェクト(A) + DBへアクセスするためのサブプロジェクト(B)
ASP.NETのプロジェクト = 普通のASP.NETのプロジェクト(C) + DBへアクセスするためのサブプロジェクト(D)
上の B = D で、これはどちらも同じバージョンのDLLなのですが・・。
0654nobodyさん
2009/07/23(木) 17:34:37ID:???別に、あなたのやり方を否定してるわけでも、自分のやり方を推奨してるわけじゃなくて、
相反する考え方があるという事なんで、あくまで一般論の話ね。
どんな想定かわからないけど、複数のものを変更しなくちゃいけない場合、
その時点で変更し忘れ等のミスが発生する可能性が高まるということ。
例えばwebサーバが複数あるとか。
>上の B = D で、これはどちらも同じバージョンのDLLなのですが・・。
ASP.NETのプロジェクトの開発で何か変更になったとき、
サブプロジェクトDのDLLを変更するのはいいけど、
その時点でBに反映させなければ、異なるバージョンの物でそれぞれが動作している
という気持ち悪い状況になるでしょ。
そういうやり方をしてるなら、Dが変更されたら、変更されたDLLをBとして反映する
必要があるから、結果的に複数のものを変更する必要があるんじゃないの？という話。
BとDが異なるバージョンのDLLで動作しているのが気持ち悪くない人というのは
そういう意味。
0655627
2009/07/23(木) 18:10:04ID:???ああ、なるほど。意味がわかりました。
> その時点でBに反映させなければ、異なるバージョンの物でそれぞれが動作している
> という気持ち悪い状況になるでしょ。
確かにそれはそうですね。
私はdeployの作業自体はスクリプトを書いて自動化してあるのですが、そこに書き忘れたら、
というのはありますね。
0656nobodyさん
2009/07/23(木) 18:33:32ID:???EntityFrameworkのほうで頑張るしかないな
0657nobodyさん
2009/07/23(木) 21:15:25ID:???DBMSは導入先の環境・都合で変わりうるでしょ。開発言語に関してはそれはまず有り得ない。
大体、「開発言語を変更しろ」なんてのは事実上「１から作り直せ」と同義なんだから、
ストアド部分だけ流用できたって、たいして嬉しくないよ。
0658nobodyさん
2009/07/23(木) 21:33:24ID:???データベースのソフト（MySQLたのOracleだのMSSQLだの）を差してるなら、
導入先の環境、都合でこれらがそんな頻繁に変わるか？
データだって移行せにゃいかんし、
そもそもクエリだってデータベース間で関数名や、その引数なんかに違いがあるんだから、
言語が統一ならどんなDBであってもまったく変わらないなんて完全な錯誤だと思うんだけど。
あるシステムでデータベースを異なる製品に変更しろなんて要求があったら、
1から作り直すのと同じだと思うし、あまりの仕打ちにそれ以上に腹が立つわｗ
0659nobodyさん
2009/07/23(木) 22:08:49ID:???ただし、金と時間はくれよな！
0660nobodyさん
2009/07/24(金) 12:02:04ID:???JavaScriptで使っているデータを1日1回、DBから生成して .js ファイルとして書き出しておくことを考えています。
その .js ファイルを IIS7でホスティングすることになるのですが、
「DBから生成して .js ファイルとして書き出しておく」ときに、テンポラリに書き出して、
.NET FrameworkのFile.Copy(src , dst, overwrite = true)で前のファイルに上書きしようと考えています。
ところが、このファイルの書き出し中にこのファイルをクライアントブラウザから要求されて
IIS7が読み込もうとしたとき、コピー中の中途半端なファイルがクライアントブラウザに渡されます。
この挙動は望むものではなくて、出来れば、コピー前の古いファイルか、コピー後の新しいファイルかの
どちらかをクライアントブラウザに渡して欲しいのです。
これはIIS7の設定で解決するのでしょうか？それとも、File.Copyを使うのが良くないのでしょうか？
0661nobodyさん
2009/07/24(金) 15:08:26ID:???コピー中はファイル存在せず
0662nobodyさん
2009/07/24(金) 15:10:12ID:???hoge.new で予め作っておく
hoge.js → hoge.bak にリネーム
hoge.new → hoge.js にリネーム
hoge.bak を削除
0663nobodyさん
2009/07/24(金) 17:35:30ID:???javascriptって.jsしか無理なんだっけ？
自分なら.jsファイル（もしくは変更されるデータ）をデータベースから取得し、
アクセスがあるたびに動的に生成するな
ファイルを作成するプログラムが、バッチ処理の役割も果たしていて、
日に1回の集計処理を行ってるとすると、若干厄介かもしれないけど
0664660
2009/07/24(金) 18:02:37ID:???それだと hoge.js → hoge.bakにrename中にアクセスされるとnot foundになるのが
嫌なのです。その2つのrenameは実際にはほぼatomicに行なわれるとは思うのですが。
>>663
確かにデータベースから流しても良いのですが、そのオーバーヘッドが嫌なのです。
(自己解決)
NTFSは次のようにtransactionをサポートしているらしいので
面倒ですが、これを使うことにします..。
Enhance Your Apps With File System Transactions
http://msdn.microsoft.com/en-us/magazine/cc163388.aspx
0665nobodyさん
2009/07/24(金) 18:24:53ID:???同じ.jsだとIEでキャッシュ扱いされそうな気がするんだが、その辺はどうなんだろ
レポート頼む
0666660
2009/07/24(金) 19:23:06ID:???> 同じ.jsだとIEでキャッシュ扱いされそうな気がするんだが、その辺はどうなんだろ
それはIISのファイルのexpireの設定次第だと思います。
0667nobodyさん
2009/07/24(金) 19:40:49ID:???0668660
2009/07/24(金) 20:25:23ID:???http://forums.techarena.in/software-development/1193025.htm
にサンプルがありますがファイルの拡張子ごとにexpireする時間を設定できるようです。
このうちjsのexpireを1hourぐらいに設定しておけば、>>665 の問題は解決するのではないかと。
0669nobodyさん
2009/07/24(金) 22:19:14ID:1HXeI2xcそんな問題おきなさそうだけどなぁ。
ファイルシステム書き換えるだけでしょ。
Windows の Copy コマンドとか使えないのかな。
0670660
2009/07/24(金) 23:37:28ID:???> 生成し終わったファイルをコピーして別のファイル上書きするだけなら
> そんな問題おきなさそうだけどなぁ。
起きます。System.IO.File.Copyでコピーした場合、ファイルコピーが開始されると
同時に、クライアントブラウザへの古いほうのファイルの転送が中断され、
結果として中途半端なファイルがクライアントブラウザに渡されます。
WindowsのCopyコマンドというのが何を指しているのかわかりませんが、
DOSプロンプトのcopyコマンドのことでしたら、これと同じ挙動のようです。
0671nobodyさん
2009/07/25(土) 01:29:42ID:WtyVOn10＞アクセスがあるたびに動的に生成するな
うわ、死んだ方がいいなこいつｗ
0672nobodyさん
2009/07/25(土) 02:03:30ID:???なんで？
それが駄目ならデータベースからデータを取得して、
動的に中身を生成するasp.netの全否定になると思うけど？
0673nobodyさん
2009/07/25(土) 02:15:27ID:???0674nobodyさん
2009/07/25(土) 02:19:13ID:???個人的には全部ソースで作ればいいじゃんと思うんだけども。
0675nobodyさん
2009/07/25(土) 02:27:23ID:???データベースからデータを取得してhtmlを生成する仕組みで動作してる
aspx全般のことを言ってるのに、asp=db必須なんて言うのは論理のすり替え
0676nobodyさん
2009/07/25(土) 03:11:46ID:???ストアドに限らず、viewやテーブル値関数、トリガーを含めてなら便利だし、結構使う
問題なく動作してるなら、別にソースからでもいいんじゃない？
メリットはデータベースを一つのオブジェクトとみた場合、データの操作はデータに近いところで行うという、
可能な操作や状態のみ閲覧でき、実装を隠蔽できるOOPのメリットと併せて考えればわかりやすいと思うけど
あとは複数クエリの実行なら、ストアドのほうが処理が速いということかな
ASP.NETとはいえ、DBとWEBサーバは別だろうから、DB-WEB間のネットワークトラフィックを最低現にできるメリットもある
0678nobodyさん
2009/07/25(土) 08:21:37ID:BV/bwvMa>>675 からなんで >>677 な意見が出るのか理解できない…。
>>673 はまぁ極端ではあるけど
>>672 の文章自体誤解を受けかねない部分はあるからまぁ仕方ないのかなって気はするけど。
まぁでもなんかとにかくかみつきたくてかみついてるような印象はあるか。
0680nobodyさん
2009/07/27(月) 09:33:53ID:???どこまで極めないといけないのか知らんが
js ファイルを作成する都度、別ファイル名にして、
aspx 側で食わせる js ファイル名を動的に変更させたらどう？
0681sage
2009/07/27(月) 10:06:33ID:???ReadOnlyのﾌﾟﾛﾊﾟｰﾃｨをtrueにすればLabel、falseにすればTextBox、みたいな。
TextBoxを変更不可にするんじゃどうしても見た目的に駄目なケースがあるんで。
0682nobodyさん
2009/07/27(月) 10:34:22ID:lA2VJ4lQ0683nobodyさん
2009/07/27(月) 14:43:15ID:???ボタンが押されたら内容をチェックして、何らかのエラーがあればエラーのあったテキスト
ボックスの背景色を変えたいんですが、方法が分かりません。
テキストボックスは動的に生成しているので、 プロパティで変更することも出来ないみたいで。
0685nobodyさん
2009/07/27(月) 15:33:45ID:???TextBoxとLabelを配置したUserControl作って、ReadOnlyプロパティとTextプロパティを作って、
TextBox.Visible = !ReadOnly Labe.Visible = ReadOnlyすればいいじゃない
>>683
public List<TextBox> TextBoxList = new List<TextBox>();
protected void Page_Load(object sender, EventArgs e)
{
for (int i = 0; i < this.Repeater1.Items.Count; i++)
{
RepeaterItem ri1 = this.Repeater1.Items[i];
TextBox textBox = (TextBox)ri1.FindControl("TextBox1");
TextBoxList.Add(textBox);
}
}
あとはお好きにどぞ
0686nobodyさん
2009/07/27(月) 15:59:05ID:???683は、validationをclient-sideで行なって、かつ、TextBoxとLabelとの切り替えもclient-sideで
行ないたいということなんじゃない？
まあJavaScriptで書くしかないわな・・。
ASP.NET、client-sideで処理するためのtool setが用意されていないので
何かとJavaScriptを書かないといけなくて面倒なんだな。
0688nobodyさん
2009/07/27(月) 17:09:31ID:???何がjQueryで大丈夫なのかは知らないが、
あまりにjQueryとの親和性が悪いので
ASP.NET4.0ではjQueryを統合するとか何とか。
0689nobodyさん
2009/07/27(月) 17:42:49ID:???○ASP.NET AJAXがあまりにjQueryとの親和性が悪いので
0690nobodyさん
2009/07/27(月) 20:19:11ID:???UserControl、ReadOnlyプロパティから考えるにサーバコントロールじゃないの？
そもそもClientでValidationを行うのが間違いだし
超簡単にやるなら、こんなでいいんじゃない。
<%@ Control Language="C#" AutoEventWireup="true" CodeFile="WebUserControl.ascx.cs" Inherits="WebUserControl" %>
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
<asp:Label ID="Label1" runat="server" Text="Label" Visible="False"></asp:Label>
public partial class WebUserControl : System.Web.UI.UserControl
{
public bool ReadOnly
{
get { return this.Label1.Visible; }
set
{
this.Label1.Visible = value;
this.TextBox1.Visible = !value;
}
}
public string Text
{
get { return this.Label1.Text; }
set
{
this.Label1.Text = value;
this.TextBox1.Text = value;
}
}
}
0691nobodyさん
2009/07/27(月) 21:07:41ID:???> そもそもClientでValidationを行うのが間違いだし
何故間違いなの？余計なトラフィック増やしたくないから、まずclient-sideで行なって、
サーバーはサーバーで再度validationを行なうのが常識でしょ。
0692nobodyさん
2009/07/27(月) 21:20:16ID:???>何故間違いなの？
ああ正確にはClient「だけ」だな 言葉足らずですまんかった
>余計なトラフィック増やしたくないから、まずclient-sideで行なって、
>サーバーはサーバーで再度validationを行なうのが常識でしょ。
入力内容をポストしてValidateするのと、JavaScriptでチェックするのの、
どちらが容量が少ないかだけの観点なら、失敗される予想回数と、
Postされるデータの容量と、Validationに必要なJavaScriptの容量が関係するから、
一概にClientでチェック＝トラフィックが低いとは言えないけどね
0693nobodyさん
2009/07/27(月) 23:45:26ID:???> 一概にClientでチェック＝トラフィックが低いとは言えないけどね
ああ、なるほど。トラフィックという観点ではそうだね。
実際は、ASP.NET ajaxでも、アクセスされるごとにサーバー側では
モデル等を再構築するのでアクセスごとのサーバーの負荷は並々ならぬものがあるので
なるべくならclient-sideで、というのは信念としてあるわけだけど。
0694nobodyさん
2009/07/27(月) 23:49:45ID:???動的生成したjsの内容をいキャッシュしとけばいいよ。
ってか良くやる方法だよ。
あんまりキャッシュとか活用されないことが多かったりするけどね。
0695nobodyさん
2009/07/27(月) 23:52:13ID:???実質的にはクライアントでも検証を行う方が有利なことが多いんじゃないかと思うけどね。
0696nobodyさん
2009/07/27(月) 23:55:29ID:???jsファイルでやりたいなら、ashxハンドラなどで、ファイルを読んでキャッシュして
リクエスト時にはそれを返す方法でもいい。
ファイルの更新時刻を見て、例えば一秒以内程度なら前の結果を返すとか自由に制御できる。
0697nobodyさん
2009/07/28(火) 00:30:07ID:???そこらへんまで行くと、完全に実装にかかるコストやなんやらとのトレードオフ
ISDNとか56kモデム全盛の時代は帯域が狭いから、
トラフィックも考慮されてたけど、今じゃよほど特殊な環境やページでなければ
トラフィックを気にして設計することなんかほとんどない
その証拠に、画面を描画するcssも、よくあるライブラリを記述するjsも、
必要な部分だけincludeしてるわけじゃなく、サーバに対して１つだけを設定してるだけでしょ
さらに言えば、今時、JavaScriptで入力チェックしてるサイトも少数派になってる
どうせ両方に実装するのならJavaScriptのほうは不必要という考えもできるからね
0698nobodyさん
2009/07/28(火) 02:26:18ID:FCPdlHYK自力でScriptをゴリゴリ実装するのは後で他人が多大なる被害を被るのでやめてくれ。
んなもんサーバ側でやればいいだろーが。
0699nobodyさん
2009/07/28(火) 08:13:31ID:???自前の関数から呼んでるのとかあったな
0700nobodyさん
2009/07/28(火) 09:19:48ID:???そんなの、いくらでもエンドユーザが改変可能じゃん。
原則は、全部のデータをサーバに丸投げして、あとはサーバ側でチェック。
仮にclient側のjavascriptでチェックしてても、全く同じチェックをサーバ
側でも再実施。だったら実装の手間隙考えて、微々たるトラヒックの事なん
か気にしない。（＝clientではチェックしない）
0701nobodyさん
2009/07/28(火) 11:02:01ID:???ってまあ言いたいことは分かってるんだけどな
0702Appri童貞
2009/07/28(火) 17:08:04ID:sYPKb5BWエラー発生モジュール kernel32.dll、バージョン 5.2.3790.4480、
エラー発生アドレス 0x0000bef7
こんなログ出た人いますか？
0703nobodyさん
2009/07/28(火) 17:20:27ID:???聞く前にぐぐれ
kernel32.dll 0x0000bef7 5.2.3790.4480
でぐぐったら、1つ目のリンクにSystem.OutOfMemoryExceptionがどうとか書いてあるぞ。
0704Appri童貞
2009/07/28(火) 17:33:53ID:sYPKb5BW0705nobodyさん
2009/07/28(火) 19:06:55ID:???0706nobodyさん
2009/07/28(火) 19:48:08ID:???0707nobodyさん
2009/07/29(水) 03:14:53ID:S6cUwBjXゴメン、今のプロジェクトで __doPostBack 書いてる。
0708nobodyさん
2009/07/29(水) 03:30:54ID:???別に問題ないと思うけど
0709nobodyさん
2009/07/29(水) 07:38:21ID:???しかしだからって、__doPostbackを自前で呼ぶことが許容できるかというと微妙。
十中八九、代替する方法があるだろうしな。
0710nobodyさん
2009/07/29(水) 19:40:32ID:???ClientScriptで動作させることが前提の非ビジュアルコンポを作ったら楽かもしれない
つか、ICallBackEventHandler試したことないから、やってみようかな
0711nobodyさん
2009/07/29(水) 20:30:18ID:???<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
<ajaxToolkit:MaskedEditExtender
ID="MaskedEditExtender1"
runat="server"
InputDirection="RightToLeft"
Mask="99,999"
MaskType="Number"
TargetControlID="TextBox1">
</ajaxToolkit:MaskedEditExtender>
と設定されたテキストボックスに、1を入力してポストバックなりすると
100,000と変換？されてしまします。
Mask="9,999" でもダメでした（1,000になってしまう）
しかし
Mask="999999" やMask="9,999,999"では問題ありませんでした。
これは何かの制限でしょうか？
0712nobodyさん
2009/07/30(木) 01:45:47ID:6Jkou0XR0713nobodyさん
2009/07/30(木) 02:45:19ID:???0714nobodyさん
2009/07/30(木) 03:29:35ID:???コールバックとポストバックは似て非なるものだから
どうしてもポストバック使いたいときもあるだろう
つか1.1まではそれしかなかったしな
ダメな理由はない
まあ、見通しが悪くなることが問題といえば問題
だがそれはコールバックでも同様
0715nobodyさん
2009/07/30(木) 06:36:24ID:???だから相関関係が無くなる
0716nobodyさん
2009/07/30(木) 07:36:36ID:???0717nobodyさん
2009/07/30(木) 08:11:07ID:???もちろん最終的には開発者の自由なんで、あくまで俺の見解として。
まず、前にも書いたがそんなことをしなくても
十中八九、正攻法で解決できると予想される。
また、他に方法がなかったとしても、
果たして裏道を使ってまで解決する要件か疑問が残る。
次に、そのような組み方は「らしくない」と感じる。
極端な例えだが、Responce.WriteでHTML出力してたり、
GridViewに仕込まれた無数のhiddenを見ている気になる。
最後に、フレームワークを使っていて、
ハッキング(裏道の利用)に手を染めたら負けかなと思ってる。
0718nobodyさん
2009/07/30(木) 14:41:52ID:???違う
最初は正しかったが、IDEでaspxの何かを変更をすることで、
結果的に間違ったものになったということ
基本的にIDEの機能や本来のやり方と無縁だからこうなる
0719nobodyさん
2009/07/30(木) 18:15:21ID:???それはスクリプトでIDなんかをハードコーティングするから悪い
スクリプトをサーバコントロールで動的に生成して出力するようにすれば
サーバコントロールとの関係は崩れない。これがAPS.NET流じゃないかな
まあ、__doPostback直接書くのはお勧めじゃない。GetPostBackEventReference使えと
.aspx側(html側)にスクリプト書いたとしても、動的に変更する必要があるところは
実行時バインド式で書いとくのが通常
0720nobodyさん
2009/07/30(木) 21:07:58ID:???これが読みにくくて判読しにくいんだよな
そもそもサーバサイドスクリプトがcsに書かれてるのも違和感だし
うまく解決できないものか
0721nobodyさん
2009/07/30(木) 21:46:45ID:???0722nobodyさん
2009/07/30(木) 22:11:19ID:???GridViewによるマスタメンテを実装しているのですが、GridViewはEnableViewStateをfalseにしないと更新が出来ないそうですね。
現在、ロジック側でConnectionStringを設定するつくりになっているので、EnableViewStateがtrueでないと動かないのです。
ということで%一行目%しかないかと思ったのですが、どこか参考になるURLなどご存知の方がいらっしゃれば、ご教授いただければ幸いです。
よろしくお願いします。
0723nobodyさん
2009/07/30(木) 22:18:30ID:???そうなの？初めて聞いた。
>ロジック側でConnectionStringを設定するつくりになっているので、EnableViewStateがtrueでないと動かないのです。
そうなの？これも初めて聞いた。
0724nobodyさん
2009/07/30(木) 22:21:01ID:???同じ環境でGridViewから更新処理してるが、EnableViewstateはTrueのままだぞ。
あと編集処理は通常CommandNameがEditであって、
更新はUpdateだから同じものでも無いはずなんだが。
まぁイベントハンドラならOnCommand辺りでフックすればいいんじゃないか。
と、ここまで書いて思い付いたが、
もしかしてObjectDataSource等をかまさずに
直接DataSourceにオブジェクトを割り当ててるとか？
0725nobodyさん
2009/07/30(木) 22:26:48ID:???VS2008+MSSQL2005
0726nobodyさん
2009/07/30(木) 22:41:33ID:???IsPostBackがtrueの時にDataBindするとイベントが発生しないということと、
ポストバックしてEnableViewStateがtrueの時だと、
取得時のデータと異なる可能性があるというデータの整合性や楽観的ロックの
関係とごっちゃになってるような気がする。
0727722
2009/07/30(木) 23:43:56ID:???というと、これはガゼ？
ttp://bbs.wankuma.com/index.cgi?mode=al2&namber=6830&KLOG=17
ttp://yaplog.jp/iamcat/archive/23
(1)削除は出来る
(2)更新も、少なくともSQLは流れてる
※UpdateCommandのSQL文弄るとエラーになるので
から、画面から入力した内容がUPDATE文に流れていないのだと判断したのですが・・・。
>>723
>>ロジック側でConnectionStringを設定するつくりになっているので、EnableViewStateがtrueでないと動かないのです。
>そうなの？これも初めて聞いた
初回は動くんですが、ポストバックするとConnectionStringが元に戻ってしまうらしいんですよ。
Page_loadで毎回代入してるはずなんですけどね・・・。
0728nobodyさん
2009/07/30(木) 23:58:28ID:???>というと、これはガゼ？
それは、GridViewにデータをバインドした後に、誰かがデータを変更した場合の話
初回アクセス時にデータを取得し、それ以降はサーバとブラウザの間でポストバックして、
データを持ち回りしているので、その間にデータベースのデータが変更されても、
変更されたデータとして反映されないということ。
>初回は動くんですが、ポストバックするとConnectionStringが元に戻ってしまうらしいんですよ。
そう考えるとConnectionStringが元に戻るんじゃなくて、表示されるデータが戻ってるだけでは？
ConnectionStringをLabelなどに表示してみて、本当に変わっているかどうかチェックしてみたほうがいい
0729728
2009/07/31(金) 00:08:52ID:???System.ArgumentException: 無効なポストバックまたはコールバック引数です。
の理由にはならないね
ただ、ポストバックで特殊なことをしてなければそんなエラーはでないから普通は関係ないはず
0730nobodyさん
2009/07/31(金) 00:14:03ID:dsR5PDEAC#でウインドウアプリ作るときはプロジェクトの設定して
Conditional属性つければ、デバッグ時のみコードを実行させることが
できますが、同じようなことをASPでできないものでしょうか？
#if DEBUGでの切り分けはあんまり使いたくないなぁということで・・・
属性じゃなくても、似たようなことができる方法教えてもらえると助かります。
0731730
2009/07/31(金) 00:16:46ID:dsR5PDEAASP.NETです
言語はC#です
0732nobodyさん
2009/07/31(金) 02:18:59ID:???>そもそもサーバサイドスクリプトがcsに書かれてるのも違和感だし
クライアントサイドの間違いじゃないのか？
サーバサイドのスクリプト（プログラム）が.csに書いてあるのは普通だろう
そのために.aspxと.aspx.csに分離してあるんだから
まあ、サーバサイドとクライアントサイドのコードが混在すると
読みにくくて判読しにくいのは同意するが、これはWEBアプリの宿命的な部分もあるしな
ASP.NETな開発で考えると、そこはコントロールの作成者が苦労すれば、
その利用者は何も考えなくてよい、ってことなんだが．．．最大の成功例はAjaxToolkitか
実際はカスタムコントロールなんて作らんとページロジックに書く場合がほとんどだろうし
作ってもコントロール利用者＝コントロール作成者な場合が多いからなｗ
0733nobodyさん
2009/07/31(金) 19:40:32ID:???WindowsUpdateはクソだな
0734nobodyさん
2009/08/01(土) 09:06:35ID:7MJE4N/Jhttp://www.microsoft.com/downloads/details.aspx?FamilyID=d34f9eaa-fcbe-4e20-b2fd-a9a03de7d6dd&DisplayLang=en
0735nobodyさん
2009/08/01(土) 11:34:44ID:???0736nobodyさん
2009/08/01(土) 11:58:07ID:???携帯向けのことも考えるとMVC以外あり得ん
0737nobodyさん
2009/08/01(土) 13:47:25ID:???0738nobodyさん
2009/08/01(土) 15:10:04ID:???って俺は思ったんだが。
他のフレームワークでのMVC開発全くやったことなかったし。
0739nobodyさん
2009/08/01(土) 15:45:55ID:???MVCならResponse.Writeで全部はき出すのとそんなに変わらん
0740nobodyさん
2009/08/01(土) 15:56:50ID:???0741nobodyさん
2009/08/01(土) 16:01:59ID:???それ以上でもそれ以下でもない。
0742nobodyさん
2009/08/01(土) 16:07:10ID:???0743nobodyさん
2009/08/01(土) 16:12:12ID:???0744nobodyさん
2009/08/01(土) 22:28:24ID:Xxdx6Cb4今までのASP.NETでは、まともに単体テストやろうとしたらかなり面倒だよね。
0745nobodyさん
2009/08/01(土) 23:07:40ID:???0746nobodyさん
2009/08/02(日) 16:46:34ID:Ql7mD23J0747nobodyさん
2009/08/02(日) 21:54:48ID:???これは便利だね
0748nobodyさん
2009/08/02(日) 22:00:36ID:???0749nobodyさん
2009/08/03(月) 00:39:33ID:???0750nobodyさん
2009/08/04(火) 10:35:52ID:???当然だろ常考。こっちは設計書に忠実に実装してるだけですが何か。
ページ切り替えとかの実装を要求されるンかなぁ。
更新系の画面でページ切り替えとか、考えることが増えてマジウザイんだけど。
0752nobodyさん
2009/08/04(火) 14:09:01ID:???■ このスレッドは過去ログ倉庫に格納されています