【質問】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落ち？）
あんまり需要ないのかもしれませんが。。。
0596nobodyさん
2009/07/15(水) 11:45:02ID:???実はプリコンパイルは関係なくて、
>CodeBehindに指定されている.csの内容を修正してもそれが反映されません。
>（aspxの内容を修正した場合は反映されています）
のあたりを詳しく聞く必要があるとみた！
.csの内容を修正しても反映されないって、例えば画面の初期化処理だとか、
ポストバック時の処理を変えたりしてみても以前のロジックが走る、
ってことかな？
.csを削除してみるだとか、新しいページ追加して確認してみるとかはどうでしょう？
プリコンパイルとかWebサイトとかの話はよく分からないので、分かる方お願いします。
0597590
2009/07/15(水) 11:55:15ID:???失礼、「Webサイト」でしたね。が・・・。
>WEBサイトならビルドしてもDLLは（見えるところには）作成されない
あれ？ もらってきたソース一式に、\binディレクトリがありますけど・・・？
えっと、binにアプリケーション名.dllを放り込むと、VSの方で勝手にそのdllへの参照設定をします。
その参照設定を外すとdllが削除され、「型 '（アプリケーション名）.Global'が読み込めませんでした」ってコンパイルすら通らなくなります。
（当然、「デバッグ」→「デバッグ開始」でも動きません）
それで、「ああ、ビルドしてdllを作り直せば、.csへの修正が反映されるのね」と思ったのですが、
「ビルド」→「Webサイトのビルド」ではDLLが作られない／更新されない・・・おや？ というところで詰まっているのです。
うーん・・・別に、開発してるときはプリコンパイルなんてしてくれないくていいのになぁ。
0598590
2009/07/15(水) 11:57:39ID:???おっと、すれ違い失礼。ええ、問題になっているところはソコですね。
ただ、>>597のような考えで「プリコンパイルされたDLLが更新されないのが問題だよね？」と思ったのですよ。
ちょっとやってみましょう＞新しいページを追加
0599590
2009/07/15(水) 12:23:54ID:???ダメですね。「型'アプリケーション名.hogehoge'を読み込めません」となります。
.csを無視してDLLを見に行ってるような感じです。
0600590
2009/07/15(水) 19:32:14ID:???結局、.net 2.0を明示的に指定して最初からソリューションを作り直し、そこにソースをコピーして再ビルドをかけました。
何が悪かったんだろう・・・。
※ツリー部にドラッグ＆ドロップでコピー可能、しかも関連ファイルまで根こそぎ持っていくのにはちょっと感心しました＞VS2008
とりあえず.csの修正は反映されるようになりましたが、やはりリビルドはしないとダメですね。
0601nobodyさん
2009/07/15(水) 19:37:54ID:???ソースファイルのタイムスタンプがおかしくなってるとか、マシンの時刻がおかしくなっているとか
プロジェクトの何かのファイルのタイムスタンプがおかしくなっているとか…。
0602nobodyさん
2009/07/15(水) 19:55:28ID:???たぶん、webアプリケーションと間違えてないか？
それか一つのソリューションに、webサイトプロジェクトと、他のプロジェクトがあって、
webサイトプロジェクトから、他のプロジェクトへの参照設定がされてる。
dllは、他のプロジェクトで作成したクラスのdllだからASP.NETの.csを変更してビルドしても
何の変化もないので不思議がってる。
こんなところだろ
0603nobodyさん
2009/07/16(木) 01:59:14ID:???<div></div>ブロックで囲んだGridViewを配置し、
ヘッダー行を固定しようと、.Freezingのお決まりのCSSを書き
GrdiViewHeaderのCSSにそのFeeezingのCSSを指定したところ、
ヘッダー行は正常に固定する事が出来たのですが、
<div>ブロックで正常に width:450pxと指定しているにも関わらずGridViewのヘッダー行(だけ)が
その<div>ブロックの幅を右横に突き抜けて表示されてしまいます。
一体何が原因なのでしょうか？
※IE７
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
指名 ｜ 年齢 ｜ 趣味 ｜ 経験年数 ｜
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A 15 ｜｜ ↑ヘッダー部分だけが突き抜けてしまう。(ここで趣味・経験年数)
B 15 ｜｜
C 15 ｜｜
〜〜〜〜〜〜〜〜〜
〜〜〜〜〜〜〜〜〜｜
0604nobodyさん
2009/07/16(木) 03:01:51ID:???表現してくれないことがあるから、そのヘッダー行に直接スタイルを適用してみたら？
というか、そういう時は、生成されたhtmlのソースをローカルなどにコピペしてブラウザで表示させるなどして、
関係ないhtmlタグを次々と消していって、目的とするタグだけで確認したほうがいいよ。
まったく関係無いと思われるスタイルが影響している場合があるから。
その目的とする表示を構成しているタグだけを残して他のタグをすべて消去し、
それでも問題が発生するかどうか確認するなどして、
他の要素が影響を及ぼしてる可能性をなるべく排除すべき。
0606nobodyさん
2009/07/16(木) 09:29:33ID:???レガシーなって、もともとはどのバージョンで作ってあったんだ？
それはWEBアプリで作ってあったのか、WEBサイトでつくってあったのか？
>>602
俺がエスパーするに、元がWEBアプリだったのを、今はWEBサイトで修正しようとしてる
今修正した部分はWEBサイトなんで、アプリケーション.DLLに反映されない
既存部分はWEBアプリなんで、アプリケーション.DLLへの参照がないと動かない
ソース全部コピーしたってことは、今全部WEBサイトになったんで動いてる
ま、こんなとこだろう
0607590
2009/07/16(木) 16:43:13ID:???そうですね。*.slnファイルも貰ったのでそのまま開いたのですが、こちらで空のwebサイト、webアプリを作成して比較してみると、webサイトの*.slnのようです。
これで開発してる、って言ってたんだけどなぁ・・・。
0609nobodyさん
2009/07/16(木) 22:19:36ID:???勝手にbinフォルダが作成されてる。その中にaspxに付随する.csやAPP_CODE配下のクラスファイルが
コンパイルされたdllが放り込まれる。aspxのヘッダはこのbinフォルダのdllを見に行くように全て書き換えられる。
別にビルドしなくても、.csのソース付きaspxをWebサーバに配置しても
IISとASP.NETは普通に解釈してくれる（まぁビルドするのと同じことしてるんだろけど）
正式リリース時は速度&セキュリティを考えてビルド方式にしたほうがいいよな。。
0610nobodyさん
2009/07/16(木) 22:25:32ID:???0611nobodyさん
2009/07/16(木) 23:25:29ID:???お前の言うWebサイトとは、VSでのプロジェクトの種類としてのWebサイトか？
一般的な意味でのWebサイトか？
一般的な意味でのWebサイトやWebアプリって言葉と
VSでプロジェクトの種類としてのWebサイトとWebアプリってのは別の話だぞ
binフォルダにDLL作るのはWebアプリだ。ソース修正したらビルドしないとDLLに反映されない
WebサイトではDLLは通常見えるところには作られてない。ソース修正したら自動的にコンパイルされ反映される
これを任意のタイミングで指定したところにDLL作らせるのがプリコンパイル
実際のところはWebアプリかWebサイトかは、VSが.ASPXのページディレクティブをどうするかだけで
ASP.NETは各ページの指定通りに動く。なので混在してても動く
0613nobodyさん
2009/07/17(金) 00:38:13ID:???0614nobodyさん
2009/07/17(金) 00:40:18ID:???・Web サイトの発行ユーティリティを使用する利点
プリコンパイル プロセスにより、コンパイル時エラー、および Web.config ファイルと他の非コード ファイル内の潜在的なエラーを検出できます。
ソース コードは、.aspx ファイル内のマークアップを含め、Web サイトから削除されます。
これにより、知的財産を保護でき、第三者がサイトのソース コードにアクセスしにくい状況を作ることができます。
サイト内のページが既にコンパイルされているため、最初の要求時にページを動的にコンパイルする必要がありません。
これにより、ページの初期応答時間を短縮できます。ただし、ページが動的にコンパイルされる場合でも、以降の要求についてはその出力はキャッシュされます。
・Web サイトの発行ユーティリティを使用する欠点
指定する発行オプションによっては、サイトを変更する際、再コンパイルが必要になる場合があります。
したがって、サイトの開発中、頻繁に変更を加えるような場合にWeb サイトの発行ユーティリティを使用することは実用的ではありません。
Web サイトの発行ユーティリティでは、コンパイル済みサイトをリモート サーバーに配置することはできません。
ローカル コンピュータまたはローカル エリア ネットワーク上の別のコンピュータにのみコピーできます。
0615nobodyさん
2009/07/17(金) 01:10:21ID:???それはMSのコメントなのか？
＞Web サイトの発行ユーティリティでは、コンパイル済みサイトをリモート サーバーに配置することはできません。
発行ユーティリティでFTP経由を指定できるんだが、これはリモートサーバとはいわないのか
0616nobodyさん
2009/07/17(金) 01:15:08ID:???0617nobodyさん
2009/07/17(金) 01:30:49ID:???http://msdn.microsoft.com/ja-jp/library/bb398992.aspx
VWDじゃなくても、発行ユーティリティを使用した欠点に、
>Web サイトの発行ユーティリティでは、コンパイル済みサイトをリモート サーバーに配置することはできません。
>ローカル コンピュータまたはローカル エリア ネットワーク上の別のコンピュータにのみコピーできます。
の記述はあるな
FTPの利用は、Webサイトのコピーツールのほうらしいなぁ
0618nobodyさん
2009/07/19(日) 17:06:01ID:???SQLは、ﾕｰｻﾞが指定した検索条件でいろいろ動的に変えたいので
SqlDataSourceのSelectCommandでは対処できないのかな？と思ってます。
そこで、「検索」ボタン押下されたときにポストバック処理の流れで
GridViewのDataSouceにArrayとかそんなようなオブジェクトを渡して描画させたいです。
そんなようなやり方でいいんですかね？
0620nobodyさん
2009/07/19(日) 19:04:33ID:???0621nobodyさん
2009/07/19(日) 19:30:24ID:???SqlCommand の Parameter 使うとか。
0622nobodyさん
2009/07/19(日) 23:37:25ID:???0624nobodyさん
2009/07/20(月) 16:03:44ID:???プロジェクトのデータセットを追加して、GridViewにBindするだけ
何かを選択させて条件で表示させたいなら、DataTable.Select("Query")を利用すればいい
0626nobodyさん
2009/07/20(月) 23:36:16ID:???SqlDataSourceなりObjectDataSourceなり
データソースを使わせた方がいいと思うが…。
ページングができませんだの、編集ボタンでエラーが出ますだの言われかねんぞ。
0627nobodyさん
2009/07/21(火) 13:52:20ID:???LINQでアクセスしています。
このDBを定期的に掃除するコードを実行したいので、タスクスケジューラから実行できる、
コンソールアプリのプロジェクトを作成しました。このプロジェクトから、↑のASP.NETのプロジェクトを
プロジェクト参照した場合、
new XXXXDatabaseEntities()
のところで、TypeInitializationExceptionが発生します。
ASP.NET側のプロジェクトのWeb.Configにあった接続文字列をこのコンソールアプリのプロジェクトの
App.Configにコピペしてきたのですが、それでは不十分なのでしょうか？
0628nobodyさん
2009/07/21(火) 17:13:29ID:???いま気づいたが、ひょっとしてDLL側にconfigを用意してそこに接続文字列を書かないといけないのか・・。
0629627
2009/07/21(火) 18:40:41ID:???・DllのConfigは書いても無駄
・App.Configの内容がXXX.exe.configにビルド時にコピーされる
この2つを理解していなかったのが原因でした。
0630nobodyさん
2009/07/21(火) 19:36:42ID:???>コンソールアプリのプロジェクトを作成しました。
ストアドプロシージャで作成してSQLのjobから実行したほうがいいんでないの？
0631627
2009/07/21(火) 20:01:58ID:???ストアドプロシージャは書くのが面倒＆書き慣れていないので、LINQで書きたいのです。
また、ログをDBに出力するメソッドなどは既に用意してあるので、
出来ればそのメソッドを用いて、DBの掃除をしたときにログを出力したいのです。
ところで、SQLのjobなら定期的に実行する仕組みがIISかSQL Serverかに搭載されているのですか？
0632nobodyさん
2009/07/21(火) 20:30:30ID:???MSSQLには定期実行するjobの機能がある。ただしExpress以上。
jobがなくても、SQLCMDだったかなで、別途ファイルに保存したクエリを実行できるから、
これをOSのタスクスケジューラーで実行するという方法もあったはず
ストアドプロシージャでも、SQL/CLRを使えば、.NETが使えるから、
Linq To Entitiesも、ログを残すこともできるんでないかな。
.NET3.5でSQL/CLR使ったことないからよくわからん。
0633627
2009/07/21(火) 20:44:49ID:???ああ、SQL Serverにジョブを定期実行する仕組みがあるのですね…。
これは知りませんでした。勉強になりました。
0634nobodyさん
2009/07/23(木) 06:02:37ID:???自分はストアド派だなぁ
その「DBの掃除」がストアド化されていて
後で「ログを出力」という要件が追加になった場合、
ストアドの中だけ弄れば済む。
「後で要件追加(変更)」なんて設計者としては最初から織り込まないといけないと思う。
→ストアド内でログ出力するロジックを追加した方が総工数は下がる
0635627
2009/07/23(木) 13:07:42ID:???> →ストアド内でログ出力するロジックを追加した方が総工数は下がる
それはストアドを駆使して書いてある場合の話であって、ASP.NETでの開発の場合、
ストアド使わずにLINQで殴り書きするほうがインテリセンスも使えて生産性が高いように思うのだが。
0636nobodyさん
2009/07/23(木) 14:04:17ID:???0637627
2009/07/23(木) 14:25:10ID:???SQL CLRは技術的に見ても面白いテクノロジーですが、
LINQに比べると書きやすさがずいぶん劣るように思います。
0638nobodyさん
2009/07/23(木) 15:01:03ID:???プロジェクト全体の保守を含めた生産性の高さが最大になる案件やシステムなら、
そうすればいいじゃんとしか言えない。
0639627
2009/07/23(木) 15:36:04ID:???ああ、ええ、まあ、そうですよね・・。
もう少し生産的な話として・・
LINQで書いたものはCLRに変換されてserver sideで実行されるのですから、
ストアドプロシージャがLINQで書ければ便利な気がするのですが、どうでしょう？
0640nobodyさん
2009/07/23(木) 15:42:28ID:???赤間さんとかの対談の形で
MSDN のページに載ってたんだけど
今探したら見あたらないな
0641627
2009/07/23(木) 15:49:30ID:???これのことですかね？
http://msdn.microsoft.com/ja-jp/data/dd919164.aspx
0642nobodyさん
2009/07/23(木) 16:03:33ID:???0643nobodyさん
2009/07/23(木) 16:11:21ID:???その複数のプログラマがみんな美しいSQL文を書けるわけじゃないし
マニュアル等々で均一化するのも大変
1人のデータベーススペシャリストに
美しいSQL文でストアド作らせてた方が効率いいだろ、と感じる
あと、ASPの場合、外部からのハックキングを想定せねばならず
データベースへのアクセス権限としてテーブルへの直アクセスを許したくない
0644nobodyさん
2009/07/23(木) 16:15:12ID:???関係するクライアントアプリやASP.NETに記述したlinqをすべて書き直すなら、それでもいいんじゃね？
単一クエリなら問題ないが、1行の操作が他のテーブルに影響を与えるなら、
ストアドプロシージャやビューをフルに活用したほうが、
処理をDB内にカプセル化できるから、仕様が変更されても、
アプリケーションを変更する必要がないし他でも簡単に使いまわすことができる。
その典型例がDBを掃除するコード。
引数が必要ないからアプリ側に影響を与えないし、
ループして複数の行に対して処理するだろうからストアドのほうが高速だし、
トランザクションも明示的に処理ができる。
0645nobodyさん
2009/07/23(木) 16:16:25ID:???select * from a;
select * from b;
...
って感じでやって取り込むのがいいの？
0646627
2009/07/23(木) 16:25:09ID:???> 仕様変更でDBのフィールドが一つ増えるたびに、
> 関係するクライアントアプリやASP.NETに記述したlinqをすべて書き直すなら、それでもいいんじゃね？
これについてですが、私の場合、DBにアクセスするコードは、サブのプロジェクトを作ってそこに集約させてあるので、
DBのフィールド1つごとに修正する箇所があちらこちらに発生するということはないです。
ただ、ストアドで処理をDB内にカプセル化するという発想やDBのスペシャリストにストアドを書かせるという発想は
私にはなかったので643,644は本当に参考になりました。ありがとうございます。
0647nobodyさん
2009/07/23(木) 16:31:51ID:???取得したいデータによって、動的に取得したいテーブルが変化するとかへんな設計してなければ、
二つのテーブルから合計値を取得するとか、簡単なものなら
クラスにクエリをたくさん記述して、各ページで再利用してる場合もある
ただ、複雑な計算が必要だったり、テーブル数が多くなる場合には、
MSSQL側に、その計算式をまるごとビューとして登録するか、
テーブル値関数として登録してる。
プログラム側では、一つの表として取得できるのでそれを描画するだけ。
0648nobodyさん
2009/07/23(木) 16:36:22ID:FURNmJTNドロップダウンリストを使用してデータを格納しているのですが
画面上からドロップダウンリストを操作した時に、表示される項目の向きが
常に下方向のみ表示できる方法はないでしょうか？
＿＿＿＿＿＿＿＿
[＿＿＿＿＿＿＿]▼
項目A
項目B
項目C
このように表示したいのですが・・・。
現状だと▼ボタンを押して表示されるデータが、リストボックスの中央から
表示されているような状況です
宜しくお願い致します
0649nobodyさん
2009/07/23(木) 16:36:55ID:???それだと、仮にクライアントアプリだと、修正されるたびに、すべてのPCにデプロイする必要があるから面倒
DBの掃除コードはコンソールアプリからだけの実行かもしれないが、
仮にコンソールアプリからでもASP.NETからでも利用したい機能が発生した場合、
一つのプロジェクト内のクラスが変更になれば、両方をデプロイなり発行しなくちゃいけない。
DBに登録すれば、それに関するストアドの修正だけで済むので、
クライアントもASP.NETもコードを変更する必要がないので。
0651nobodyさん
2009/07/23(木) 17:10:18ID:???よほどの理由がない限り、DBMSへの機能依存を前提とした設計は
避けたほうが無難じゃね？
0652nobodyさん
2009/07/23(木) 17:18:22ID:???コンソールとASPでやってて、SQLを別プロジェクトにしてる時点で、
同じDLLをASPとコンソールの二つからみてるわけだから同じじゃん
異なるバージョンのDLLで稼働してるのが気持ち悪くない人なら別にいいけど。
>>651
DBそのものの変更の可能性を考えるのなら、
使用言語が変更しづらくなる可能性も考慮しなきゃｗ
ストアドなら、そこにアクセスして操作できる言語なら
言語に依存せずに利用することができるとも言えるｗ
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:???実質的にはクライアントでも検証を行う方が有利なことが多いんじゃないかと思うけどね。
■ このスレッドは過去ログ倉庫に格納されています