09/09/06 23:11:26
ASP.NETの標準的な組み方が分からない…。
www.asp.netのサンプルやらMS謹製含む書籍を見てもみんなバラバラ。
BLLとDALに分けるんじゃなかったのかよと。
ある本では型付きデータセット最強と書いてて、
またある本では型付きデータセットは複雑な業務ロジックに使えないから
自前のエンティティクラスをバインドすべしと書いてあって、
いや、型付き無しのデータセットで十分みたいな論もあったり。
もう訳分からん。
で、「このやり方ならOKだ！」みたいな文句に惑わされてホイホイリンクを辿ると、
どっかの会社の独自フレームワークか、SqlDataSource一つだけのしょぼいサンプルとか。
もう疲れたよﾏﾏﾝ
20:nobodyさん
09/09/06 23:23:40
>>19
まあ、それぞれ開発者によって前提が違うので言ってることがバラバラになるのは当たり前だと思うよ。
鵜呑みにするんじゃなくて、自分でそれぞれの手法のメリットとデメリットを書き出してみて、
自分の立場で一番優れていると思う手法を採用すればいいだけのこと。
それはASP.NETに限ったこっちゃないけど。
21:nobodyさん
09/09/06 23:41:50
エンティティクラス→VS2008以降、LinqToEntityを使用
型付きDataSet→クエリ固定でVSが自動的に作成するDataSet
型無しDataSet→クエリを動的に生成して自分でDBからデータを取得
という位置づけで書いてるんじゃね？
型無し、型付きは、それぞれが問題じゃなくて、それを実装するコストが問題なんでしょ。
クエリ固定で、where文ぐらいを動的に生成すればいいぐらいなら、IDEが自動で作ってくれる
型付きDataSetでも十分。複雑なクエリで動的にクエリを発行しなけりゃならい場合は、
型付きデータセットの定義を作製するのが面倒だから、別に型付きでなくていいよって話ではないかと。
22:nobodyさん
09/09/07 04:57:31
>>19
まず、前提としてるバージョンをよく確認しないとだめだぜ
あとは対照としてる規模とかにもよって変わるしな
で、最適な組み方は設計方法によっても違う
標準といわれる設計がないので、標準的な組み方もないんだよ
23:nobodyさん
09/09/07 23:10:36
ちょっと経験談を聞かせてくれ。FormView のテンプレートで Insert と Edit
の中身がほとんど一緒なんだけど微妙に違う、みたいな時どうしてる? Edit
だとキー項目は見せてもいじらせないとか。
DRY 原則に従い、CompositeControl 継承したカスタムコントロールを
毎回自作しているが、これで良いのかどうかわからん。慣れてしまえば楽
だが、そもそも ASP.NET ってなるべくコード書かないようにするための
仕組みだし、メンテナが変わった時の引き継ぎがめんどいなあと悩み中。
24:nobodyさん
09/09/07 23:36:23
>そもそも ASP.NET ってなるべくコード書かないようにするための仕組み
ASP.NETをフレームワークとして捉えるならその通りなんだけど、
カスタマイズ性の乏しいFormViewとかGridViewは、
あると便利的なコントロールなんで、
フレームワークの一つとして捉えるのは本末転倒だと思う
なんて言うのかな
個々に特化したサーバコントロールは料理に例えると、めんつゆであり、ポン酢。
蕎麦やしゃぶしゃぶとか、それぞれにマッチした料理にはぴったりだけど、互いの流用はできない。
基本となるサーバコントロールは醤油。鰹だしとみりんでめんつゆだし、柑橘類があればポン酢にもなる。
自分なら基本的なサーバコントロールの醤油だけ使って作成するかな。
25:23
09/09/08 00:07:14
>>24
言ってる意味がわからんが、FormView はテンプレートで自由に
レイアウトをカスタマイズできるし、ObjectDataSource と組み
合わせて DB アクセスするにはもってこいじゃないの?
醤油だけで作るってのはつまり、FormView を使わないってこと?
俺にしてみりゃあり得ん話だが、なぜそうするのか理由が知りたい。
26:nobodyさん
09/09/08 00:21:04
>>25
既に書いてるけど、めんつゆに合う料理ならめんつゆでいいし、ポン酢ならポン酢に合う料理に使えばいい。
そのかわり、基本はめんつゆやポン酢なので、許容範囲が狭い。
醤油なら、めんつゆもポン酢も作れるし、もちろん醤油ベースのステーキソースも作れる。
ポン酢やめんつゆで料理が簡単に作れるのはいいけど、
それに捕らわれて料理全般の多様性が減ったり、
ベースとなるめんつゆやポン酢以上の味が作れないと感じるから。
もちろんポン酢を利用してる人でも、醤油ベースで様々な料理は作れるけど、
そこにポン酢のメリットや利便性を醤油に求めるのはおかしいと思うってこと。
27:23
09/09/08 00:42:27
>>26
ありがとう。醤油は好きだが理解しあえないのが良くわかった。
>>23 を読み返して自分でも意味不明だったので再度書いてみる。
FormView の InsertItem と EditItem の内容がほとんど同じだけど微妙に違う
という状況はメンテナンス性が悪いし、コードも重複するので何とかしたい。
同じ内容の検証コントロールをそれぞれに貼るとか耐えられない。
そこで、モードによってレイアウトと機能を切り替えるカスタムコントロール
を自作し、FormView の InsertItem と EditItem にそれぞれ貼り付けている。
これでレイアウトと機能が再利用できる。もちろん DataBindings の設定は重複
するが、現状ではそこを追求しても仕方がないので割り切っている。
これは割と良くある状況だと思うのだが、経験談を聞かせてもらえると嬉しい。
28:nobodyさん
09/09/08 01:02:56
>これは割と良くある状況だと思うのだが、経験談を聞かせてもらえると嬉しい。
ない
FormViewなんてつかわない
29:nobodyさん
09/09/08 07:59:50
>>27
漏れのやってるプロジェクトもFormView使ってるが、もう諦めてPerlかなんかで置換スクリプト書こうと思ってる。
クラス継承して作ってもインターフェースのどのメソッドが呼ばれているか分からんし、MVCとかDynamicDataとかで使うとなると内部の手続き調べるのが大変。ソースコピペを自動化した方が良いと思う。
30:nobodyさん
09/09/08 09:02:28
やはりどこも同じか。
>>27
>FormView の InsertItem と EditItem の内容がほとんど同じだけど微妙に違うという状況
この微妙というのが、どの程度の微妙さかにもよるんだけど、
ウチは開き直って登録と修正を別のUserControl, FormViewにしてしまうことが多い。
確かに分けると重複する部分が出てくるが、
経験上、一つにまとめてしまうと度重なるメンテを受けた後、
それぞれのモードの専用処理が恐ろしいことになりやすい。
また、そもそも初期状態でも、モードごとの専用処理を抜き出すと
それだけで結構な分量になっていることがある。
じゃあ1クラスで全て完結させるのは諦めて、
完全に共通な処理を外出ししてから、
それぞれのモードを別クラスとして扱った方がよくね？という流れ。
要するに、FormView, GridViewのモード切り替えって使えねぇなという(ry
31:nobodyさん
09/09/08 14:25:57
>>27,30
プログラミングASP.NET 3.5によると、
編集と挿入が要件の異なる別個の処理であることを理解してください
らしいので、そもそもその二つを共通化しようとする方向が間違ってるらしいぞ
だからと言って登録専用FormView、修正専用FormViewを作るのはやり過ぎな気がするが
表示用FormViewあったら、１ページにFormView合計三つ定義することになるんだよな？
32:nobodyさん
09/09/08 15:54:59
結局、自分でTextBoxなりCheckBoxなりをポトペタして
登録、修正画面を作ったほうが楽ってことだな
DBへの登録、修正の画面パターンなんて数パターンしかないだろうから、
一度作ればひな形ができて、あとは使いまわすだけじゃん
なんでFormViewとかGridViewとか、使い回しの悪いものを使うのかわからん
33:nobodyさん
09/09/08 20:30:40
>>32
一覧表示から修正画面に移る時には、
コントロール一つずつに対して値の設定をしていけとな。
34:nobodyさん
09/09/08 20:48:57
1ページにFormViewを3つ定義するなら、そのほうがよほど楽だな
しかもFormViewという足枷が外れる
作成する便宜に捕らわれすぎて、本来何のために開発してるのか
見失ってるんじゃないか？
35:nobodyさん
09/09/08 21:11:53
>>32
FormViewはDynamicControlが使えるからじゃまいか。
本来の使い方をすれば、一々入力フォームの形式を考えずに済むぞ。
36:23
09/09/08 22:04:35
>>28
CompositeDataBoundControl 実装するの? すげーや。
>>29
自動化は賛成だが、動きは理解しとかないとまずいだろ。
>>30
登録と修正は単一の FormView で ChangeMode するだけだと思うが。
>>31
登録も修正もレイアウトと入力チェックは似たようなもんだろ? そこを共通
化したいんだよ。実際の更新作業はデータソースがやるからまた別の話。
>>32
ASP.NET と ADO.NET っていう道具立てで FormView を回避するほうが
わからんよ。
>>34
FormView が足枷なわけないだろ。開発者を助けてくれるのに。
>>35
DynamicData って Oracle でも使えたっけ? 一応、Oracle と SQLServer の
両方に対応せよということなので、使ってなかったが。
37:23
09/09/08 23:06:13
どうも話がかみ合わないので、最後の悪足掻きをしてみる。
FormView を使う時には、以下のようにカスタムコントロールを使うのが
理想的ではないか、というのが現時点での俺論。カスタムコントロールには
編集に必要な全てのコントロールやバリデータが含まれているから、わざわざ
FindControl せずに済むというメリットもある。テンプレートを使いながら
タイプセーフを実現できるわけで、この利点は捨てがたい。
FormView
|
+- DataSource -> データオブジェクト(Select/Insert/Update/Delete)
|
+- InsertItemTemplate -> カスタムコントロール(mode=Insert)
|
+- EditItemTemplate -> カスタムコントロール(mode=Update)
当然ながら、Select の引数には GridView の SelectedValue をバインドして
一覧と同期させている。
しかし、このカスタムコントロールの実装は Joe Coder には敷居が高いのでは
ないか。デザイナで aspx をいじれば済むという手軽さを失うわけだから。
標準化とあわせて、このあたりの折り合いをどうつけているのか、うまい落し
どころはないか、というところが知りたいのっす。
38:nobodyさん
09/09/08 23:27:54
>>36
>FormView が足枷なわけないだろ。開発者を助けてくれるのに。
足枷だろ？FormViewで実現できない仕様を渡されたら嫌な顔するだろ？ｗ
つーか、要求定義の段階でユーザからの要望をはねつけてるだろｗ
ASP.NETの使用上できませんとかいって。本末転倒。
39:nobodyさん
09/09/08 23:31:48
>>37
そんな面倒なとこするなら、初めからポトペタで済ませたほうがよっぽど楽だろ
InsertもUpdateもほぼ同じロジックで流用できる。
新規か編集か、つまりIDがあるかないかで、InsertするかUpdateするかを分けるだけだ。
バリデーションもすべて共有できるし、編集されたくないコントロールはReadOnlyにするだけ。
大したコスト削減にもならんのにFormViewに固執する理由がわからん。
40:23
09/09/09 00:24:25
>>38
ASP.NET でやりやすいように設計するだけの話。それ以上でも以下でもない。
>>39
FormView を使わなかったらデータ項目とコントロールのやり取りを全部手で
書く必要があるし、SQL も泥臭く書くことになるんじゃないの? 俺にとっては
そっちのほうが面倒なんだけどな。
41:nobodyさん
09/09/09 03:21:58
>>40
（SQL）データソースの更新機能だけでDB更新が事足りる
再利用しないカスタムコントロール作るのを余計な作業と思わない
(結果として)同じ処理をするコードは極力一つにまとめないと気が済まない
まあ、こんな感じだな
俺には一つも当てはまらねぇｗ
いまだ1.1の修正させられる俺に言わせれば、RepeaterでOK
それ以外は使いたければ使えば、って感じ
42:nobodyさん
09/09/09 07:28:11
>>40
>ASP.NET でやりやすいように設計するだけの話。それ以上でも以下でもない。
つまり顧客の要望であってもASP.NETでやりにくければ、そういう設計にはしないってことだな。
んー、自社向けなら許されるけど、納品する立場ならこんな発言許されないだろ。
プログラマ（というか設計者）として失格だと思うぞ。
>FormView を使わなかったらデータ項目とコントロールのやり取りを全部手で
>書く必要があるし、SQL も泥臭く書くことになるんじゃないの?
それのどこが問題なの？
求められる要求に対して、これらのコントロールが活用できるならすればいい。
しかし、そのコントロールを使わないと面倒で泥臭くて嫌と考えたり、
ましてASP.NETでやりやすいように設計するなんてのは本末転倒。
それに、ASP.NETが開発効率を上げるための仕組みだ。
結果、副次的にコードの記述が少なくなるところまでは理解できるが、
だからそういったコントロールを使わなきゃいけないと思うのは完全に間違いだろ。
あくまで利用できるところにのみ利用し、難しいところは基本的なコントロールで代替する。
ASP.NETは、基本的なコントロールを利用するだけでも開発効率は十分に高い。
>俺にとってはそっちのほうが面倒なんだけどな。
俺が思うプログラマが決して言ってはいけない言葉。それは「面倒」。
43:35
09/09/09 07:45:19
>>36
うちはMSSQLだわ。
DBMSからメタデータが抽出出来るなら動くと思うが、ムリぽいな。
44:35
09/09/09 07:52:48
>>42
すれ違いになるが、その「面倒」はこの先納品した客も被る訳だ。面倒を顧客の要望だからと言ってただ言いなりに実装するのは、自分にも顧客にも良い結果にはならない。
まあこういうフレームワークは日本の箱庭的システムにはそぐわないかもね。
45:23
09/09/09 08:04:03
>>41
俺のところだと SQL 手書きが発生するのは全体の 2 割以下だな。それもこれも最新の
ASP.NET が使えるおかげ。
>>42
わかった。お互い別の道を歩もう。
46:nobodyさん
09/09/09 08:57:27
なんか、手段と目的が逆転してる人がいるよね。
47:nobodyさん
09/09/10 09:08:58
ASP.NET（Frameworkは2.0）でWEBサイト開発して配置用にインストーラーを作った。
インストール先のサーバーにはFrameworkが1.1と2.0が入ってて、規定のサイトのASP.NETは1.1に設定されている。
この場合配置されたサイトは1.1で動作するようになってしまうんだが、インストーラー側で2.0に切りかえれないものだろうか？
配置後に手動で切り替えれば済むことなんだけど、なんとかならないかな。
web.configのsupportedRuntime要素を設定してもダメみたいだし。
48:nobodyさん
09/09/11 03:46:12
>>44
FormViewを使わないことで面倒なら、もう何もしないほうがいいな
49:nobodyさん
09/09/11 03:52:35
つーか、その面倒解消のためFormViewを導入しようとして逆に効率落ちてるじゃん
本末転倒
50:nobodyさん
09/09/11 08:22:52
つか正直ASP.NETって帯に短し襷に長しだよな
51:nobodyさん
09/09/11 16:36:40
>>50
その評価はまちがってる
ASP.NETが中途半端なんじゃなくて、用意されてるコントロールが中途半端なんだよ
52:nobodyさん
09/09/11 18:15:27
>>51
中途半端じゃないとコンポーネント屋が困るからな
53:nobodyさん
09/09/11 19:07:44
コントロールは、基礎的なものさえあればいいんじゃないのかな。
応用的なの作っても、結局特定の用途向けみたいな感じで、
万人向けじゃなくなっちゃうし、
かといってカスタマイズがこんだけできるんですって作ると、
今度は複雑になって逆に万人向きじゃなくなる感じがする。
今までで困ったのは帳票ぐらいかな。
こればかりは買ったぞ。数十万とかで。
あとはrepeaterさえ攻略すればなんとかなる感じ。
ところでformviewが話題になってるけど、
外部制約とかの整合性制約がある場合も対応できるの？
商品名を選択させてIDを入れるとか、
重複しない商品コードを入力させるとか。
試そう試そうと思っているうちにそのままなんだ。
54:nobodyさん
09/09/12 13:14:52
俺、コントロールをポトペタする派なんだけど、
登録フォームをどうやってFormViewで作るの？
何かしらバインドしないとFormViewって表示されないよね？
55:nobodyさん
09/09/12 17:18:05
よーし、ちょっとテストしてみようかな
56:nobodyさん
09/09/12 23:04:00
formviewやってみたけど、うまくカスタマイズできなくてわけがわからない(´･ω･`)ｼｮﾎﾞｰﾝ
わからないのは、いまのところ4つ
・ParentTable→ParentID ParentCode ChildID
・ChildTable→ChildID ChildCode
があって、ParentTable.ChildIDはChildTableのChildIDと同じで、
FormViewでChildCodeを入力することによってParentTableのフィールドを更新なり挿入なりしようとしている場合。
１）
テーブルがこんな感じで、ParentTableにChildTableの主キー（ChildID）を保持してる場合、
FormViewのChildIDをChildCodeに置換してlistboxなどで表示する方法ってある？
２）
同時実行制御はデータソースでのデータバインド時にParentTableの実行制御はできると
思うんだけど、ChildTableが変更された場合にも同時実行制御の対応できる？
（入力中にChildTableが編集される可能性を排除するため）
３）
２）と近いけど、ボタンをクリックしてから、実際に保存するまで、
ParentTableとChildTableのトランザクションはどうやって管理すればいい？
（同時実行制御で確認してから、実際に書き換えするまでのトランザクション管理）
４）
ChildTableの行数が増えると、ChildCodeを何かしらの手がかりに検索して
入力（表示）させる必要があると思うんだけど、FormView内にコントロールがあって、
それを選択可能？
うーむネットでも情報が少ないし疲れたよﾏﾏﾝ
57:nobodyさん
09/09/12 23:54:01
子が親のIDもってるんじゃなくて、親が子のIDもってるのか？
それだと親と子は１：１にしかならないような
１）
置換するの意味がわからん
普通に結合するなりなんなりでChildCodeの項目も用意するだけでは？
２）
実行制御って具体的に何のこと？
DBへの排他制御なら、基本的に楽観的ロックなのでDBへのロックはなしだろ
４）
子テーブルの行数増えても親テーブルにもってるIDで見るだけじゃないのか？
お前の考えてる入力イメージがまったくわからんぞ
58:nobodyさん
09/09/13 00:13:12
>>57
例えばparent＝受注テーブル、child＝商品テーブルみたいな感じ
parent:Childは1:n
１）
>置換するの意味がわからん
childテーブルの商品idを、商品コードに置換をするってこと。
表示時はそれでいいけど、
更新時には商品コードを商品id(childID)に置換をする必要があるでしょ？
２）
>実行制御って具体的に何のこと？
商品コードをlistBoxで選択をさせる場合、人間が商品コードを選択し、
それと対になる商品id(childID)をpostBackで受けることになると思うのけど、
その間にマスタが変更されてしまった場合、
childIDとcodeが一致しない可能性が発生しない？
３）
>DBへの排他制御なら、基本的に楽観的ロックなのでDBへのロックはなしだろ
楽観的ロックでchildTableのdateTime値から変更が無いことを確認しても
それを確認してから、実際に、parentTableを更新する間に編集されちゃうかもしれんから、
トランザクションで管理をしたくならないかなと思って。
４）
>子テーブルの行数増えても親テーブルにもってるIDで見るだけじゃないのか？
商品コードを、listBoxに入れて選択をさせることはできるかもしんないけど、
商品をたくさんの条件から検索して、それをformView上のlistBoxなり、
textBoxなりに商品コードとして入力したいこととかない？と思って。
そんでその方法がよくわからんと。
59:nobodyさん
09/09/13 00:45:56
なんか楽しそうだな。俺も後で参加しよう。
60:59
09/09/13 02:44:02
何回読んでもいまいち意味が分からん。
61:nobodyさん
09/09/13 02:59:49
>>60
具体的に書けばいいのかなｗ
１）
textBoxに商品コードを入力させ、
その商品コードから商品テーブルの商品idを取得して、
商品idを受注テーブルに挿入することはformViewでできる？
２）
１）と似たような感じで、
商品コードをlistBoxから一覧で入力させるとき、
受注テーブルは楽観的ロックでいいけど、
商品テーブルは商品コードを入力中に、
裏で誰かが商品マスタを編集して商品コードを変更させてしまっても
楽観的ロックで排除してくれる？
３）
２）で楽観的ロックで確かめられないとしたら、
商品テーブルから商品コードと商品idが一致するのか確かめなくちゃだけど、
商品テーブルの商品コードの存在を確かめる→受注テーブルに挿入するの間に
商品コードが編集される可能性があるから、トランザクションで管理できる？
４）
textBoxに商品コードを入力させるとき
他のウィンドウや他のformから商品コードを検索して
formView上のtextBoxに入力させることはできる？
こんな感じなんだぜ。うぇーはっはっは
62:nobodyさん
09/09/13 05:09:22
>>61
とりあえずFormViewの仕事とDataSourceの仕事を区別しよう
FormViewで出来るかと言われれば、全部出来る
コードレスで出来るかというなら、FormView周りにかぎれば、
条件つきでたぶん出来る（４以外）
お前が望むような動作をするDataSourceがあれば、って条件だがな
63:59
09/09/13 08:56:53
1)
できる。FormView関係ない。
2), 3)
個人的にコードレスではできないと認識している。
（2.0しか知らないから、今はどうなのか知らん）
4)
できる。FormView関係ない。
寝る。途中で飽きた。
URLﾘﾝｸ(www1.axfc.net)
64:nobodyさん
09/09/13 17:58:37
さんくす
FormView(+ObjectDataSource)は使うけど、
結局、相当に長くコードを書くのが必要なんだな。
コードみて大まかなやり方がわかったよ。ありがとう。
クエリを書くのが2割になったというので興味があったんだけど、
テーブルってほとんど他とリレーションしてるから、
結局は更新時にチェックをしなくちゃいけないよね。
そうすると何かしらのクエリの記述が必要になりそうだね。
既存のプロジェクトを調べたら、子テーブルのIDを持ってないテーブルって、
都道府県マスタとか、商品種別のマスタとか、一部のマスタぐらいしかなかった。
だから2割になるというより、最大で2割ぐらい減るのかなという印象。
これなら、無理してformView使うよりも
コントロールのポトペタのほうが、制限が少なくていいかなぁと思ったんだけど、
どうなんだろう。もちろん自分の場合の話だが。
ところで、文章から、2)と3)なんかを
FormViewで実装した経験がないように見受けられるけど、
そんなチェックはしないことが多いのかな？
整合性で問題がでるパターンが想像できると思うのだけど。
それとも、子テーブルのIDを持つようなテーブルを
更新したり、挿入したりすることがあまりないような
シンプルなサイトの開発が多いのかな？
ちょっと気になったもので。
65:nobodyさん
09/09/13 18:44:22
親が子のIDをもつ親子関係ってのが理解できん
それで親と子が１：ｎになるんだよな？
通常の業務で入力するような範囲で、マスタの変更チェックなんてしないとおもうが
おまえのとこはそんなに頻繁にマスタが変更されるのか？
66:nobodyさん
09/09/13 21:14:34
>>65
第一に、前者と後者は関連性はないよね。
n:nでも、n:1でもチェックが必要なのは同じことだから。確認のため。
1:nの関係はよくあると思うよ
商品->商品種別、会社->都道府県、支社->社員、会社->担当、受注->明細とか
親->子の例は、
そんな確認ができるのかなという疑問に思っただけなのと、
他のテーブルの主キーを持っていないテーブルが、
マスタ関連だけだったというだけなんで、
常にマスタのチェックをしなきゃいけないということを、
言いたかったわけじゃないんだ。ごめんよ。
でも、自由入力させる場合の商品コードは、
その存在チェックと主キーへの変換は必要だよね？
入荷した商品の、在庫の引き当て数量チェックとかも。
似た動作をいろいろ見ると、いろんな確認が必要で、
他のテーブルの確認をせずに、
無条件で更新できるような入力箇所って
思うより少ないのねって思ったの。んでもって、やっぱり手書きなんだなと。
掲示板とか、ゲストブック的な、
他のテーブルを意識しなくても済む単純な入力や編集には
便利だと思うんだけど
67:59
09/09/13 21:35:45
一応言っておくけど、俺はコントロールポトペタ派。
>そんなチェックはしないことが多いのかな？
登録対象商品がまだ有効かどうかのチェックはする。よくする。
ただし、普通、マスタの更新（UPDATE）なんてしない。ありえない。
やるなら削除後に新規登録、または新規登録のみ。
そうすれば登録対象が急に別物にすりかわるなんてことはなくなる。
1:nの関係はもちろんよくあるが、親が子のIDを持つことはありえないと思うんだが。
支社テーブルは社員IDを全部持ってるの？各社員（子）が支社コードもってればよくない？
68:65
09/09/13 22:27:45
>>66
１：ｎの関係はよくあるが、親が子のIDもった状態でどうやって
親：子が１：ｎの関係を作れるんだ？
その親に対する子はその親がもってるIDの子１件だけだろ
まさか同一IDの子が複数いるとか言わないだろうな
後半に関しては、個人的意見だがIDとコードを両方持つ設計は少ないと思うぞ
データとしては入力されるコードを格納すればいいんだし
コードとID別持ちで、コードからID引いて格納するって設計がまあ特殊なんだと
在庫引当の例とかは、ビジネスロジックとしてのチェックの問題だ
ビジネスロジックをコードレスなんてもともと無理だと思うがな
それは更新の問題じゃなくて入力内容チェックの問題
FormViewだろうがなんだろうが画面を表示する機能に直接関係ない
69:nobodyさん
09/09/14 05:04:37
>>67
>登録対象商品がまだ有効かどうかのチェックはする。よくする。
するよね？
するってーと、ObjectDataSourceなんかでチェックして、
だめなら、だめの返値返して、エラー表示する処理とかになるよね。
>1:nの関係はもちろんよくあるが、親が子のIDを持つことはありえないと思うんだが。
>支社テーブルは社員IDを全部持ってるの？各社員（子）が支社コードもってればよくない？
ごめん。急いで書いたので、一部、不適切な関係があるね。
というか、自分が、どうやら、親と子を逆に捉えてるのかな。
他のテーブルの主キーを持ってる方を親だと、ずっと思ってたよｗｗ
商品マスタ->商品区分マスタ、取引先->都道府県マスタ、社員マスタ->支社マスタとか。
70:nobodyさん
09/09/14 05:11:29
>>68
>親：子が１：ｎの関係を作れるんだ？
上でも書いたけど、どうやら俺が逆に書いてるようだｗ許してくれ(´；ω；`)ｳｯ…
でも、在庫引き当て時とかのチェックは1:1でも1:nで・・も(ry
>後半に関しては、個人的意見だがIDとコードを両方持つ設計は少ないと思うぞ
どっちにしろ、コードの存在確認はしなきゃなんないでしょ？
編集されたかの楽観的ロックじゃなく、
存在しないコードを入力させない存在チェックとして。
>FormViewだろうがなんだろうが画面を表示する機能に直接関係ない
というかね
>45 名前： 23 [sage] 投稿日： 2009/09/09(水) 08:04:03 ID:???
>俺のところだと SQL 手書きが発生するのは全体の 2 割以下だな。それもこれも最新の
>ASP.NET が使えるおかげ。
から、formView+dataSourceでクエリの手書きが2割以下になると思ったのよ。
そのぐらいすごいんだと。
ほんとは、調べるとそうでもなくて、
過去の経験からは、ほとんどチェックが必要だったりして、
ObjectDataSourceでコード書かないといけないので、
自作のクラスで処理するのと、あんま差はないなと思ったということ。
で、dataSourceを利用しないで、formViewを使うメリットってなに？
という話になるとおもうんだけど、
上のサンプルみると、各コントロールのインスタンスからデータを取得してるから、
ポトペタするのと変わらないようにみえる。
フィールド値のバインドを自動的にやってくれるぐらい？
という感じがしてるんだけど、という感じ。
うーん、なんかいまいちよくわかんないな・・
71:65
09/09/14 10:05:53
入力チェックは確かに必要だが、それは画面表示の機能(=FormView)の範疇でも
DB更新の機能(=DataSource)の範疇でもない（入力チェックをObjectDataSourceでやるのは
俺は間違ってると思う。DataSouceのもとになってるクラスでチェックするべきだと）
で、SQLの手書きが２割以下ってのは、俺は言いすぎだとは思う
ただ、純粋にSQLを書くという作業に限ってみれば、SQL書くところすべてに
SQLDataSourceつかえば、確かに自分でSQL書くことは少ないとはおもうが
それはアクセスでクエリビルダ使ったらSQL手書きしなくていいです、ってレベルと同じ話
必要なSQL文の数が減るわけじゃなくて、それを書く作業が減るだけ
DataSource使わないFormViewのメリットなんてないと思う。というか
FromViewはDataSource前提に設計されたコントロールだと思うが
DataSourceつかうことにメリットがあるんじゃなくて、使わないことにデメリットがある
72:nobodyさん
09/09/14 19:50:49
>>71
DataSourceの元になるクラスという？
こういった場合にはObjectDataSourceでSELECT、INSERTなどのクエリを生成して、
コントロールにバインドするんじゃないの？
73:nobodyさん
09/09/14 19:52:33
DataSourceの元になるクラスという？
↓
DataSourceの元になるクラスというと？
74:23
09/09/14 21:41:06
>>71
入力チェックは aspx.cs の仕事だと思うがなぁ。SQL 手書き 2 割以下というのは
ObjectDataSource で TableAdapter を使うパターンが 8 割を占める、という意味。
たとえ複数テーブルの更新が発生したとしても、内部的には TableAdapter を使い
回す。手書きが必要なのはバッチ処理ぐらい。まあ、プロジェクトにもよるがうちは
テーブル数と画面数が大体 200 ぐらいだな。コードマスタが 50 以上あったはず。
75:nobodyさん
09/09/14 23:51:43
んー、確かにTableAdapterでいける部分は使うべきかな…。
うちは今一切使わない方針だけど。
なんかたまにASP.NET本来の原初的な組み方をしなきゃならないって考える波がくる。
で、MS本読み直すと「あー間違ってたのかな」と思ったり。
「Javaから来たヤツは全てを自前クラスで用意しようとする。
そうする利点は認めるがASP.NETでは…」みたいな論調だし。
で、軽く組み直してみたら、やっぱりハマるんだけどw
76:nobodyさん
09/09/15 00:04:23
Dataの引っ張り方は人それぞれだから別とすると、
それならDataSourceと切り離してFormViewだけのメリットって何？
って話だな？
これとは別にTableAdapterを使うのはいいけど、データのソートとか抽出とかはどうしてる？
クエリかかないならTableAdapter.Fill(DataTable)して、DataTable.Select("")してるってこと？
これだとSQLからデータ抽出して、メモリに蓄えて、そこからまたSelectして
無駄が多いような気がするんだが。
77:nobodyさん
09/09/15 02:15:05
結局のとこ、SQLを手書きする量が減るだけで、SQLの量そのものが減るわけじゃないってことだな
SQL書く作業がTableAdapter定義する作業になっただけ
昔のADO.NETでは、DataAdapterでのUPDATEは使えねえってのが定説だった気がするが
TableAdapterになって使いものになるようになったのかな？
78:nobodyさん
09/09/15 03:43:03
ただ全部の項目を埋めて、挿入、更新するだけなら結構使える
複雑なことしようとすると、TableAdapter用のクエリの手書き必須
挿入時に論理削除を意味するIsDeleteをいじられたくないのでfalseで固定したいとか
サブクエリで抽出した内容を取得して挿入したいとか。
挿入したときの主キーを取得するのも手書きが必要だったような。
あと上にもあるけど動的にクエリを発行できないので
検索条件に従ってWhere句を作成するとかは無理だったはず。
かといってDataTableのSelectメソッドをWhere句の動的生成の
変わりに利用すると、いちど全部のデータを取得するので、
行数が多いとデータの取得に時間がかかる。
そのたありがLinqToSQLやEntityFrameworkで解決してると思うんだけど、
LinqToSQLは終了の方向だし、EFもなんとかしてくれって言う人が多くて、
まだ微妙なところ。
79:23
09/09/15 07:39:06
>>76
うちでは Excel の仕様書から TableAdapter を自動生成していて、SelectList メソッド
にソート引数も指定できるようにしてるよ。内部的には ORDER BY に変換する。
>>77
やっかいなのは、SELECT するのは VIEW だけど更新もしたいケース。そんな時は
Update メソッドの中で、個々の TableAdapter を使い回す。それで対応できなければ
SQL 手書き。
>>78
WHERE の動的作成は頻出パターンなので、TableAdapter の自動生成時に作り込んで
いる。つまり、検索条件を引数にもらう SelectList メソッドの中で、引数が null じゃ
なければ WHERE に追加している。こうすると、画面側では検索条件をバインドする
だけで済む。
80:nobodyさん
09/09/15 17:37:59
>>79
>TableAdapter を自動生成していて
>WHERE の動的作成は頻出パターンなので、TableAdapter の自動生成時に作り込んで
それでSQL手書きが２割以下になるのか。それなら納得
しかし、自動生成されたSQLを使うのはどうもあまり乗り気になれん
TableAdapterにしてもDataSourceにしても、SQLは完全にラップされて
アプリ側から見えなくしてるわけだし、その方向が正しいのはわかるんだけど
アプリ側でSQLもシームレスに使いたいっていうと、LINQな方向に行くのかねぇ
でもあれもSQLがそのまま通るわけじゃないしなぁ
81:nobodyさん
09/09/15 19:25:00
>>79
>TableAdapter の自動生成時に作り込んでいる。
>つまり、検索条件を引数にもらう SelectList メソッドの中で、
>引数が null じゃなければ WHERE に追加している。
これどうやるの？
TableAdapterで、条件に従ってWHEREを追加とかできたっけ？
82:nobodyさん
09/09/15 23:02:34
Yのつくとこがすきそうな手法だな・・
83:nobodyさん
09/09/15 23:29:57
自動生成時に作り込む＝クエリビルダでクエリを作る＝細かいところは手書きでクエリ修正
とかじゃないだろうなｗ
84:23
09/09/15 23:52:09
>>81
Excel マクロでコード生成するんだからパターンさえ決まれば何でもできる。
Fill 系のメソッドで引数チェックして WHERE を組み立てるなんざどこでも
やってることでしょ。
85:nobodyさん
09/09/16 01:27:00
>>84
そのFillなんちゃらの引数によって、クエリを作ったりできたっけ？
自分はできないと思っていたので、できるのなら教えてほしい。
環境はVS2005+SQLServer2005
86:nobodyさん
09/09/16 01:32:33
途中で送信してしもた
環境はVS2005+SQLServer2005で、TableAdapterのFillなんちゃらのメソッドで、
引数に従ってWHEREを作成するなんて無理だと思ってた。
Fillなんちゃらがストアドを呼び出してて、
ストアド側で引数によってクエリのWHEREを組み立ててるならわかるけど、
それはクエリを書いてるから手書きクエリの削減じゃないしなぁ。
87:nobodyさん
09/09/16 06:02:19
>>84
>Fill 系のメソッドで引数チェックして WHERE を組み立てるなんざどこでも
>やってることでしょ。
Fillなんちゃらって、TabelAdapterのか？
SQL指定したらメソッドの中身はウィザードで勝手に作られてるぞ
すくなくとも自分でコードは書いてないから、動的にSQL作ったりはしてない
これをいじるぐらいなら俺ならTableAdapterなんて使わん
>>86
実現させる方法をいろいろ考えたが
部分クラスか継承させたクラスでFillなんちゃらを全部自前で実装すればできそう
SelectList メソッド ってのもよくわからんし、自動生成されてるのは
TableAdapterだけじゃないのかもしれんが、そのへんは>84じゃないのでわからんｗ
たとえストアドで操作してても、そのストアドが自動生成されているなら
「手書き」クエリは減ってるとは言える
まあ、なんかしらの開発用フレームワークあるんじゃないかって感じだな
88:23
09/09/16 07:26:21
>>86,87
TableAdapter は Excel の仕様書からマクロで自動生成してるんだって。Fill とか
SelectList とか名前はどうでも良くて、要するに ObjectDataSource の Select
メソッドに選択できるメソッドの中で、引数をチェックして WHERE を組み立てる
ロジック込みで、コードを自動生成している。TableAdapter をウィザードで作って
いるわけではない。これを「手書き」と思うなら、まあどうぞ御自由に。
89:155
09/09/16 16:20:34
>>88
すまん、どの引数なのか、ウィザードとは何のことかさっぱりわからん。
よければ質問に答えてくれないか？
>ObjectDataSource の Selectメソッドに選択できるメソッドの中で、
>引数をチェックして WHERE を組み立てるロジック込みで、コードを自動生成している。
Ｑ１ どの引数をチェックしてWHERE文を作成してるの？
１．ObjectDataSourceのSelectメソッドの引数
２．TableAdapterのFillなんちゃらメソッドの引数
３．その他のメソッドの引数（どのメソッド？）
Ｑ２ WHERE文を組み立ててるのはどこ？
１．ObjectDataSourceのSelectメソッド
２．TableAdapterのFillなんちゃらメソッド
３．Excelのマクロ
４．その他（どこ？）
Ｑ３ 自動生成するクエリの範囲は？
１．すべてをExcelのマクロで作成
２．WHERE文以外をExcelのマクロで作成、WHERE文のみQ2のメソッドで、Q1の引数から作成
３．すべてをQ2のメソッドで、Q1の引数から作成
４．その他（どこ？）
90:nobodyさん
09/09/16 16:21:32
失礼、名前は無関係
続き
>TableAdapter をウィザードで作っているわけではない。
Ｑ４ TableAdapterそのものはどうやって作ってるの？
１．データセットデザイナ
２．その他（なに？）
Ｑ５ 作成したWHERE文から前のクエリとWHERE文はどこに登録してるの？
１．すべてのクエリをTableAdapterに登録
２．WHERE文から前をTableAdapterに登録、WHERE文はDataTable.Selectメソッドで登録
３．その他（どこ？）
Ｑ６ クエリをどこに登録してるの？
１．拡張子.xsdのxmlファイルのに手書きで作成したクエリを追加
２．データセットデザイナのクエリ構成ウィザードを使って作成したクエリを登録
３．データセットデザイナのクエリ構成ウィザードからクエリビルダを使って作成したクエリを登録
４．その他（なに？）
91:nobodyさん
09/09/16 16:35:02
データアクセス層のクラスを自動生成するって話はわかるんだが
その自動生成されてるものはTableAdapterといえるのだろうか
そもそもTableAdapterって何だって話になるんだが、MSDNによると
>TableAdapter は、DataAdapter の機能を向上させるためにデザイナで生成されるコンポーネントです
らしい。
当然TableAdapterと１００％互換のあるクラスも作成可能なんだろうが
それを生成したからといってTableAdapterを自動生成っていうと誤解を招くとおもうな
ObjectDataSourceでの使用が前提なら、あえてTableAdapterと互換のあるものにする必要もないし
SQL手書き量が減ってる最大の要因はこのデータアクセス層クラスの自動生成のおかげで
けっして最新のASP.NETのおかげではないってのも誤解を招いた原因の一つだな
92:nobodyさん
09/09/16 18:30:04
いや、既存のTableAdapterに、自前のクエリを何かしらの方法で登録してるんでしょ？
じゃないと話がつながらないし、
もしExcelのマクロとやらでクエリを書いてるから自動だってのなら、
これはツール（Excel）のおかげでASP.NETのおかげじゃないから
2割以下なんて結論に至るはずがない。
>45 名前： 23 [sage] 投稿日： 2009/09/09(水) 08:04:03 ID:???
>俺のところだと SQL 手書きが発生するのは全体の 2 割以下だな。それもこれも最新の
>ASP.NET が使えるおかげ。
DataSetデザイナでは、WHERE文を動的に発行することは不可能だから、
みんなどうやってるのかを聞きたいんだと思うのだが。
※DataSetで動的にWHERE文を作るのは不可能というと誤解を招くと思うが、
考えられる場合の数だけ引数の異なるFill～メソッドを作れば可能だが、
これは半固定なのでこれは動的発行じゃないし、
ストアドプロシージャでも可能だけど、これも事実上、クエリは手書きとかわらんし、
DataTableのSelect使えばソートやフィルタリングはできるが、これもクエリの動的発行じゃない
93:23
09/09/16 21:41:11
>>89
Q1=2, Q2=2, Q3=1
>>90
Q4=Excel マクロ, Q5=TableAdapter の定数, Q6=Q5 と同じ
要するに、TableAdapter.cs 全体を Excel マクロで吐き出している。全部。WHERE
の動的生成もその中にある。種も仕掛けもあるよ。
>>91, 92
あーなるほど、>>45 の発言が混乱させてたのか。たしかに ASP.NET のおかげじゃ
ないね。手書き 2 割以下は ASP.NET のおかげではなく、Excel マクロのおかげ。
元レスは ASP.NET 1.1 の環境だったから、単純に FormView が 使える3.5(2.0 も)は
いいぜ、という程度のノリだった。すまんかった。
94:nobodyさん
09/09/16 22:11:35
∧∧
ヽ(･ω･)/ ｽﾞｺｰ
＼(.＼ ノ
､ﾊ,,､ ￣
￣
でDataSourceと関係なく、FormViewのメリットってなに？
本来、ポトペタするコントロールに、フィールド名を登録するだけでバインドしてくれるところ？
95:nobodyさん
09/09/16 22:50:54
なんと比べてのメリットって話もあるが、1.1と比べるなら
FormView(DetailsViewも）のメリットは、データソースの単一レコードにバインドでき
レコードのナビゲーションを操作する機能まで取り込まれているところがメリットかと
1.1で単一レコード表示させたら、レコード移動と画面の更新を全部自分でやらんとダメだからな
双方向バインドで自動更新なんておまけみたいなもんですよｗ
96:23
09/09/16 23:02:19
>>94
それもあるが、レイアウトを自由にカスママイズできるってのと、あとは登録処理が
FormView.InsertItem(false) で OK なところとか、Update の時に元々の入力値も
引数で一緒にもらえるところとかね。使ったことないなら使ってみたら?
>>95
ナビゲーションは逆に使ってないな。GridView との連動パターンしかない。
それと、双方向バインドで自動更新は不可欠だろ! これのおかげでどんだけ楽に
なってるか。
97:nobodyさん
09/09/16 23:33:22
本当に日本語が不自由な奴だな
>レイアウトを自由にカスママイズできるってのと
レイアウトの自由度はポトペタ>>>>>>>>>>>>>>>>>>>>>>>>(越えられない壁)>FormViewだろ？
なんでレイアウトの自由度がポトペタに対してFormViewのほうがメリットあるんだ？
>あとは登録処理がFormView.InsertItem(false) で OK なところとか、
そんなのFormViewじゃなくても作り方次第
>Update の時に元々の入力値も引数で一緒にもらえるところとかね。
そんなのFormViewじゃなくても作り方次第
>それと、双方向バインドで自動更新は不可欠だろ! これのおかげでどんだけ楽になってるか。
多くの人はなってないんだよ。
おまえだけがエクセルでやってるから楽なの。
FormViewの利点を述べたいがために強弁してないか？
ASP.NETでクエリを書くのが2割になったとか、
レイアウトを自由にカスタマイズできるとか、
作り方次第でどうとでもなることをFormViewのメリットだと述べたりとか、
自分がやっている方法に固執してFormViewは便利だと述べたりとか。
98:23
09/09/17 00:05:04
>>97
作り方次第のところはそう言うならまあ頑張ってくれやって感じだが、双方向バインド
は Excel とは何の関係もないよ。
99:95
09/09/17 01:07:19
>>96
>レイアウトを自由にカスママイズできる
レイアウトのカスタマイズなんてFormView以外でもカスタマイズできる
これはFormViewのメリットでも何でもない
>ナビゲーションは逆に使ってないな。GridView との連動パターンしかない。
ナビゲーションの真意が伝わってない気がするな。FormViewでレコードを移動するって話じゃないぞ
レコードが移動されたときに新しいレコードにバインドし直すって話だ
いちど、FormViewつかわないで一覧からカレント行取得して詳細表示するコード書いてみ
このコードを自動でやってくれるのはかなり楽
データ更新は、SQL書くのなんてパターン決まってるから難しくはない
（それこそ自動生成で８割まかなえるほどに）
ただ、ビジネスロジックのチェックはそうはいかんし
単純な更新でないと使えないってのが感想だ
>>97
作り方でどうにでもなるのはその通りなんだが、問題はその作りこみが
FormViewで不要や楽に実現できるようになるかどうかだろ
レイアウトの件はまあ同意だが、FormViewにもポトペタすればある程度自由にできるぞ
登録処理は、単純な更新に限れば楽なる
UPDATEの元値は、DataSet使わないならかなり有効な機能だと思う
1.1には単一レコードを想定したバインドコントロールはないんで、
その点でFromViewにはメリットはあるから、使えるとこなら使えばいいかと
逆にデメリットは、自由度が下がるってことか
それでもある程度コードかけばカバーできる範囲だと思う
100:nobodyさん
09/09/17 05:26:24
>>99
上のほうにナイスなたとえがあるけど、まさにその通りだと思ったな
FormViewは麺つゆ
ウドンやソバを作るのには便利だし美味しい
だけどいくら加工してもベースが麺つゆだから味が似てしまう（応用度が低い）し
麺つゆだから酢醤油や砂糖醤油にはならない。
ポトペタの醤油は手間はかかるがより多くの料理に利用できる。
こんなとこだろ
101:nobodyさん
09/09/17 10:42:52
ウェップフォーム上の全チェックボックスのチェックをオフにしたいんですが、方法は
ありますでしょうか？repeaterの中にあってIDが固定じゃないのでべた書きすることが
出来ません。
102: [―{}@{}@{}-] nobodyさん
09/09/17 12:15:57
>>101
サーバ側でならRepeater.ItemDataBound イベントで処理する。
クライアント側でならJavaScriptで走査して処理する。
103:nobodyさん
09/09/17 15:36:36
チェックボックスOFF程度でバインドし直すのもな。
俺ならサーバー側もforeachで回す。
104:nobodyさん
09/09/17 16:26:00
なにをみてforeachで輪せばいいんですか？
105: [―{}@{}@{}-] nobodyさん
09/09/17 17:23:14
>>104
Repeaterの中をIDでFindControl
106:nobodyさん
09/09/17 23:30:47
FindControlでもいいけど、コントロール名を
ハードコーディングしたくない俺は大体再帰で回す。
protected void button_Click(object sender, EventArgs e) {
clear(this.Repeater1.Controls);
}
protected void clear(ControlCollection controlCollection) {
foreach (Control control in controlCollection) {
if (control.GetType().Equals(typeof(CheckBox))) {
((CheckBox)control).Checked = false;
}
if (control.HasControls()) {
clear(control.Controls);
}
}
}
107:nobodyさん
09/09/18 05:33:22
type='reset'なhtmlボタン配置したらどうだろうか
まあ俺なら、ページ出力時にクライアントサイドのスクリプトを動的に生成して出力しとく
チェックボックスオフにするためだけにポストバックさせたくない
今ならAjaxでやるのもありなのかもしれん。updatepanelだっけ？
その場合、Repeaterの中全部更新されるよね？
108:nobodyさん
09/09/18 09:52:05
>>107
CheckBox以外のControlsもあったらどうすんの？
109: [―{}@{}@{}-] nobodyさん
09/09/18 10:44:13
>>107
JQueｒyとか使うと楽ちんだわな
110:nobodyさん
09/09/18 15:09:35
>>108
その場合はその項目もリセットされるわな
それがまずいかどうかは>101の判断だろう
まあ、一番楽な方法としてリセットボタン考慮する価値はあるかと
111:nobodyさん
09/09/18 15:15:51
>type='reset'なhtmlボタン
そういえばそんなのもあったな。すっかり忘れてたわ。
112:nobodyさん
09/09/18 19:03:46
俺もClientスクリプトに一票
113:nobodyさん
09/09/19 03:13:45 ZjH1gzNN
今のプロジェクトはASP.NETで作ってるんだが、どうしても必要なのでJavaScriptも死ぬほど書いてる。
自分で実装してて思うんだが、こんなの俺以外に絶対に保守出来ない。
つーか俺自身でも3か月後には多分保守出来ないｗ
難しいシステムを無理やりWebで作るのはほんとアホとしか思えないぜ。
114:nobodyさん
09/09/19 04:39:22
うちは基本的にクライアントスクリプトの自前書きは禁止だなぁ@2.0環境
5行で書ける処理でもサーバー側でできるなら、そっちでやってもらってる。
>難しいシステムを無理やりWebで作るのはほんとアホとしか思えないぜ。
特に帳票とか帳票とか帳票とかな。まずデザインで死ねる。
更に、あたかも関数だらけのExcelのような動作を求められたりして死ねる。
入力項目50個超で1つ入力すると各項目を色々再計算／再描画とか言ってくるけど、
50個AutoPostback = trueな状態にするとブーブー言ってくるのは確定的に明らか。
こうなるとJavaScriptの出番になってしまい>>113みたいになって死ねる。
で、仕様変更があった時にJavaScript側で更に色々判定する必要がでてきてまた死ねる。
この経験からうちではクライアントスクリプト禁止令と、
「出来る出来ないで言えば出来ますが…は、ハッキリNoと言う」という
超基本的なことを徹底するようになった(´;ω;`)
115:nobodyさん
09/09/19 15:13:10
教えて下さい。
コードビハインドで作られてるんですけど、3つのaspxが指すコードが全て同じものを指してる
んですが、これっていいんですか？まあ動けばOKという格言もありますが。
Form1.aspxとForm2.aspxとForm3.aspxが全部FormCom.aspx.csを指してます。
ちなみにFormX.aspxは3つとも微妙に違っていて、載ってるコントロールなんかも違います。
その辺はFindcontrolしてnullかどうかをちゃんとチェックしてるようなんですが。
でもまあ、通常は基底クラスに全部詰め込んで、あとは各画面に対応するクラスを継承するのが
正しい方法だと思うんですが。
116:nobodyさん
09/09/19 17:07:25
>>115
>3つのaspxが指すコードが全て同じものを指してる
この発想はなかったわ。どう考えてもNGだろ。
117:nobodyさん
09/09/19 19:01:05
メリットが思いつかないな
118:nobodyさん
09/09/19 19:39:44
メリット
単純にコード記述量を減らせる。つまり試験工数も減るし、バグも減る。いい事尽くし。
3つのパターンで画面入力させるんだけど、画面上の項目が微妙に違う。(画面上の100項目の
うち10項目ほど）無論、3パターンを1画面でまかなって、区分によって項目のVisibleを制御
するのでもいいんだけど、いっそ3画面分のaspxを用意して、裏のcsは共通にしてしまおう、
と。デザイン指定が超絶シビアなので、Visibleで出したり隠したりとかしたくなかった。
基底クラスを継承、の場合でも、例えばボタンをクリックした場合のイベントはやっぱ3画面
それぞれ必要だよね。csが1つならとことんコード量を減らせる訳で。
まあ、「コード量が少ない」と「メンテしやすい」は等価じゃないけど。
119:nobodyさん
09/09/19 19:40:53
>>116
すいません、NGの理由ってなんでしょうか？
120:nobodyさん
09/09/19 20:00:26
自己ﾌｫﾛｳ
開いてる画面によってはコントロールがあったり無かったりするので、不用意に
TextBox1.Text = "ほげ～";
とか書けなくなる。全画面共通で必ず存在しているコントロールじゃない限り、一々FindControl
でコントロールを探さなきゃならない。
デメリットってこれぐらいだと思うンすけど。
121:nobodyさん
09/09/19 21:09:11
余りに阿呆らし過ぎて説明する気もおきん。
コボラ相手にしてる気分だ。
いいと思うならやればいいんじゃないンすか？
122:nobodyさん
09/09/19 21:16:18
>>121
ページが最終的にコンパイルされる仕組みを理解していれば、特に何の問題も無いわけだが？
理解出来ないなら黙ってた方が無知を晒さずに済むと思われ。
123:nobodyさん
09/09/19 21:22:24
ここのページに個別にJavaScriptを設定したくてもできなかったりとか
コントロール名を変更しても反映されなかったりとか
不必要なイベントハンドラメソッドが増えるとか
インテリセンスが意味をなさなくなってバグの温床になるとか
124:nobodyさん
09/09/19 21:32:36
それは、そういうデメリットもあるから、メリット・デメリットを天秤にかけて考えてね。
ってだけの話で、やってはいけない。という理由にはならない。
でもまあ、個人的には動けば正義だと思ってる
ちなみに「不必要なイベントハンドラメソッドが増えるとか」これだけ意味不明。
125:nobodyさん
09/09/19 21:45:24
>ちなみに「不必要なイベントハンドラメソッドが増えるとか」これだけ意味不明。
ボタンの数だけイベントハンドラメソッドが増えるでしょうが。
各ページに5個のボタンがあって、それぞれ別動作してたら15個のメソッドが存在することになる。
>でもまあ、個人的には動けば正義だと思ってる
保守性が下がるからやってはいけない
他人が見てもわけわからないことになるからやってはいけない
重複させるとインスタンス時に余計なサーバ資源を消費するからやってはいけない。
インテリセンスの動作が無駄になりバグの温床になるからやってはいけない。
エラー発生時にハイライトされた行が、どのページのエラーなのか一別しか分かりにくいからやってはいけない。
ページ初期化時に表示ページとは関係無い初期化にリソースが消費されるのでやってはいけない。
>それは、そういうデメリットもあるから、メリット・デメリットを天秤にかけて考えてね。
>ってだけの話で、やってはいけない。という理由にはならない。
デメリットのほうが圧倒的に大きいから「やってはいけない」ということでしょ。
単に自分がやってることを否定されたくないから、難癖つけて認めさせたいようにしか見えない。
126:nobodyさん
09/09/19 21:46:50
各ページに5個のボタンがあって、それぞれ別動作してたら15個のメソッドが存在することになる。
↓
3枚の各ページに5個のボタンがあって、それぞれ別動作してたら15個のメソッドが存在することになる。
127:nobodyさん
09/09/19 21:55:05
>126
普通、そういうケースではさすがにこんなヒネたコードは書かんだろ常考。
各画面にボタンが5個あって、ページに関係なく処理が同じ（前画面に戻るとか）
↓
15個のメソッドが必要なところを5個で済む
ていう事を言いたいんｼﾞｬﾏｲｶ？
128:121
09/09/19 22:11:27
>>122
アホかw本来別にすべきものをまとめて、
何がコンパイル時には一緒になるからだ。
App_Code以下が単一dllになるからって、
1クラスに全部まとめて書くか？書かないだろ？
なぜだ？責務が異なるものは、分けるのが当たり前だからだろ？
ある画面専用の処理が追加になったらどうするんだ？
他の画面からしたら、全く関係のない処理があるクラスを実装してることになるぞ。
リファクタリングを一回でもやったことがあれば、
それがどんなにアホなことか分かるよな。
月日が経って、そのクラスを実装するaspxが増えたらどうなる？
その度にif文やFindControl判定が増えていくのか？
なんとも素晴らしい設計だな。
仕様変更時には影響範囲が特定できず、
ある画面だけの修正なのに、処理が重なっているために
全画面の動作検証を行わねばならなくなったりしないか？
つか、高凝集密結合が良くないなんて、学生でも分かるだろ？
で、業務上、そういうことにはならないように気を使ってますとでも言うのなら、
先に述べたように、お好きにどうぞってこった。
129:nobodyさん
09/09/19 22:26:02
多分元の質問者は「技術的に問題ありますか？」って事を聞きたいだけだと思われ。
そういう意味では「注意深く作るなら、別に問題はない」が回答。
ただし「将来的なメンテとか拡張とか修正とか考えると、3画面分まとめて1ソースに
すると身動き取れなくなったりしない？止めとけば？」ってのが周りのアドバイス。
130:nobodyさん
09/09/19 23:06:31
>>127
>ちなみにFormX.aspxは3つとも微妙に違っていて、載ってるコントロールなんかも違います。
って言ってるぞ。
131:nobodyさん
09/09/20 06:26:46
知識のない奴が一人前に提案して
不備を指摘されると逆ギレ
誤りを認めたくないから強弁するってガキの流行なんか？
132:nobodyさん
09/09/20 14:01:24
>>130
で？
133:nobodyさん
09/09/20 14:03:21
俺が認めない方法は許さない。
って馬鹿の粘着ｷﾓｲ
>129 で出てる回答が全て。あとは自分で判断しろってことで終了。
134:nobodyさん
09/09/20 15:36:43
>>133
技術的に問題があるかどうかなんて聞いてないよ
本人は技術的には問題ないことを理解した上で、メリットデメリットの話をしてるんだから。
技術的に問題無いことを理解している発言は>>122でしてる。（技術的に）何の問題もないと。
メリットとデメリットの話をしようとしているのは>>120を見れば分かる。デメリットうんたらかんたらと。
135:nobodyさん
09/09/20 16:07:08
エスパー登場
136:nobodyさん
09/09/20 16:48:16
なんか、ある事例を今の我が事のように感情移入してしまう人が居ますが、
その3画面での共用する方法はある意味、仕組みを熟知して使い倒してますなｗ
ネイティブアプリでの共有ライブラリ、DLLの様ように。
禁止事項ではないから、開発&保守が効率的であればそれも選択肢としてアリだと思う。
137:nobodyさん
09/09/20 17:05:18
熟知しての実装なのか、無知ゆえの実装なのかはともかく（後者っぽいけど）、ケースに
よってはそういう手もあるのかと知ってちょっと感心した。
ビハインドコード共有！そういうのもあるのか
みたいなｗ
機能的に全く完全に差異がないけど、デザイン的にどうしようもない（ある仕入先と別の
仕入先で全く異なるデザインの画面）ケースなんかでは有効かも。
138:nobodyさん
09/09/20 17:09:01
>なんか、ある事例を今の我が事のように感情移入してしまう人が居ますが、
４：主観で決め付ける
>ネイティブアプリでの共有ライブラリ、DLLの様ように。
６：一見関係ありそうで関係ない話を始める
>禁止事項ではないから、開発&保守が効率的であればそれも選択肢としてアリだと思う。
１：事実に対して仮定を持ち出す
10：ありえない解決策を図る
12：決着した話を経緯を無視して蒸し返す
というか自演乙
139:nobodyさん
09/09/20 17:54:42
というか、aspxのページを新規生成すると、
ロジックを記述するパーシャルクラス(ページなんちゃら.aspx.cs)と、
コントロールなどのメンバ変数を宣言する.aspxが自動生成するパーシャルクラスの
二つが作られるわけでしょ？
後者はVSがページ毎に自動生成するからaspxと1対1になってる
コードビハインドは、そのメンバ変数を参照してる（からインテリセンスで補完してくれる）わけで
いくらpageのインスタンスを所有していて、そこからFindControlで操作したいコントロールを見つけられるとしても
メンバ変数として宣言されてるコントロールを一切使用しないなんて、
asp.net以前にオブジェクト指向の設計として間違ってるような気がするのは俺だけ？
クラスで例えれば、
メソッド内では決して参照しないまったく関係無いコントロールのインスタンスをメンバ変数として保持し、
メソッド内で操作したいコントロールのインスタンスは、すべてメソッドの引数として得て操作してるような感じ。
じゃあ、メンバ変数として所持してるインスタンスってなに？
その都度無駄にコントロールのインスタンスを生成するの？ってな感じになると思うんだ。
技術的に問題ないとか、問題なければやってもいいだろとか別次元の話だと思うんだけど。
動けば害はないし、禁止されてないからということで、1行ごとにThread.Sleepをしかけまくるみたいな。
140:nobodyさん
09/09/20 17:58:03
君さ、もう「宗教上の理由で俺は断固として認めない」とでも言えば？('A`
141:139
09/09/20 18:05:49
なんだかわからんが、初の書き込みなんだが
というかで始めたのがまずかったか
142:nobodyさん
09/09/20 18:13:57
すまんが
技術的な見地
思想的な見地
メンテや修正といった見地
で分けて議論？してくれ。じゃないと収束せんだろ。
>技術的に問題ないとか、問題なければやってもいいだろとか別次元の話だと思うんだけど。
じゃあ技術的には問題なし、思想的に不可。でいいじゃん。
143:nobodyさん
09/09/20 18:38:22
>>142
いや、技術的に問題ないわけないじゃんね。
それ以前の話。
無駄なあえてわざと無駄な変数宣言をしてインスタンスを生成することは
動くけど技術以前の問題だろ？
1行ごとにSleepかませたり、ところどころ無駄な変数を宣言してインスタンスを生成したり
技術とか思想以前の問題
144:nobodyさん
09/09/20 19:12:59
どうしても「俺が認めないものは認められない」つー馬鹿がいるな。
1行ごとにsleepかけようが、ASP.NET的には全然OK。
でもそういう実装が実際に許されるか否かは、そのアプリの目的に依存するんで可否を決
めようがない。
InProcで動いてる時にSessionに1GBのobjectを突っ込むのも、ASP.NET的には問題なし。
でもほんとにそんなことをしていいかどうかは求められてる仕様や環境次第。
技術以前の問題だっつーなら、技術以前の問題と技術的な問題に切り分けろよ。
145:nobodyさん
09/09/20 19:58:30
>>144
>どうしても「俺が認めないものは認められない」つー馬鹿がいるな。
お前のことか？
>1行ごとにsleepかけようが、ASP.NET的には全然OK。
>InProcで動いてる時にSessionに1GBのobjectを突っ込むのも、ASP.NET的には問題なし。
アホかよｗ
>そのアプリの目的に依存するんで可否を決めようがない。
>ほんとにそんなことをしていいかどうかは求められてる仕様や環境次第。
ほとんど否だろ？もしくはしないほうが望ましいとされるだろうな。
自分に有利な条件を想像すんなよ。
「認められる仕様があるかもしれない」って都合の良い言い方だよな。
90-10ぐらいでほとんど認められない状況を、可否は判断できないとして
強引に50-50まで戻せるんだからｗ
なんで、そこまでしてむりくり正当化して自分の無知を認めたがらないのかね
146:nobodyさん
09/09/20 20:04:08
>>144
その意味不明な改行の仕方といい自演バレバレですよ？
147:nobodyさん
09/09/20 20:15:01
ID出ない弊害だな。
148:nobodyさん
09/09/20 20:39:04
IDなんていくらでも変更できる
自演の中身は文章で判断するしかない
偉い人にはそれがわからんのですよ
149:nobodyさん
09/09/20 21:09:34
ぶっかけ秋田。どっちでもいい。
150:nobodyさん
09/09/20 21:19:00
>>148
こういうとき使うのは逆。
151:nobodyさん
09/09/20 23:35:57
>>145
とりあえずお前が、技術的に問題ない という日本語の意味を理解してないのは理解した
152:nobodyさん
09/09/21 00:39:40
ここまで全部俺の自演
153:nobodyさん
09/09/21 11:40:40
>>151
とりあえずお前が、日本語を理解してないのは理解した
154:nobodyさん
09/09/21 14:04:37
複数のaspxが同じcsを指すのって普通に使ってたんだが・・・
褒められた作りじゃないにしても、いまの所これが原因で動作がおかしくなったとかは無い。
155:nobodyさん
09/09/21 14:16:06
>>154
＞褒められた作りじゃないにしても、
いや、だからみんなこれを言ってるんだろ
。
156:nobodyさん
09/09/21 15:20:59
なに？またループさせたいの？
褒められた作りじゃないが、有りといえば有り。
↓
いや無しだろ。動く動かない以前の問題だ
↓
最初に戻る
157:nobodyさん
09/09/21 16:47:03
TableAdapterを使う場合にトランザクションかけられないのが
ものすごく不便に感じていたがReflection使えばよかったんだな。
URLﾘﾝｸ(weblogs.asp.net)
ちょっと無理矢理な気もするが、自前で全部用意するよりはかなり楽になりそうだ。
今まで「TableAdapterつかえねー」の一念だけで、ろくに調べもしなかった自分に反省。
個人的にはこれで使わない理由はなくなった。ちょっと試してみよう。
158:nobodyさん
09/09/21 18:47:39
必要ないインスタンスが生成されるのを「有り」とする人が多いのに驚いた
>>157
TransactionScope使えばかけられるんじゃないの？
URLﾘﾝｸ(blogs.msdn.com)
リフレクションは便利だけど、遅いしコンパイルのチェックが入らないから美しくない
最低減で使う分にはいいけど、メソッドの呼出とかで使いまくってる奴をみると
C#という静的言語を一体なんだと思っているのかと小一時間チクビ舐めてやる
159:nobodyさん
09/09/21 18:51:28
>>156
俺も無しに一票だな
今、テレビ見てたんだが、「第二音声では英語で実況しています」というテロップが日本語で入っていた
つまり、こういうことだ
日本語でアナウンスしてしまったから、英語で聞きたい人に伝わらないけど、
いちおう第二音声で実況しているから有り
↓
いや無しだろ。英語で実況しているしていない以前の問題だ。
↓
最初に戻る←いや戻らない戻らないｗｗｗ 英語でテロップだせよｗｗ
160:157
09/09/21 18:52:15
>>158
TransactionScopeは、むかーしになんかの理由で
使えないなーって判断した記憶があるが忘れたな。
もう一回調べてみる。ありがとう。
161:nobodyさん
09/09/21 19:04:48
MS-DTCが使えないとか、サーバの関係かな？
使えると便利なんだけどね。TeansactionScope。
結局なんだかんだいって、SQLサーバにすべてクエリ登録して、
アプリ側ではストアドだけ呼び出すのが正しいのかなという気がするよ。
162:nobodyさん
09/09/21 22:11:19
駄目な相対化の例をこんなとこでも見るとは・・・
163:nobodyさん
09/09/22 00:49:26
いつか誰かが突っ込むだろうと思ってずっと待ってんだけど、なんで誰も指摘しないの？
馬鹿っぷりを曝け出してる様をみてﾆﾔﾆｱしてんの？
つーわけで
不 要 な イ ン ス タ ン ス っ て 何 ？
TextBox1,2,3があるページと、TextBox1,3,4があるページの両方が同じ分離コードをさしてる
として、片方のページを表示してるとTextBox1,2,3,4のインスタンスが出来るとでも思ってる
の？馬鹿なの？死ぬの？
164:nobodyさん
09/09/22 11:06:33
>>163
ASP.NETの勉強をし直してからまたおいでね
165:nobodyさん
09/09/22 12:44:19
>>139
> メンバ変数として宣言されてるコントロールを一切使用しないなんて、
> asp.net以前にオブジェクト指向の設計として間違ってるような気がするのは俺だけ？
逆だろ。
自動生成されたメンバ変数を使いつつ、コードを共有したいから、
共通の基底クラスを継承するのではなく、コードビハインドを共有するんだろ。
共通の基底クラスを継承する場合は、
基底クラスでは全てのコントロールをFindControlしなければならないが、
コードビハインドの共有なら、共通のコントロールに限り、メンバ変数が使える。
166:nobodyさん
09/09/22 13:11:19
>>163
彼の主張する不要なインスタンスについては>>139に書いてある内容だと思う
>ロジックを記述するパーシャルクラス(ページなんちゃら.aspx.cs)と、
>コントロールなどのメンバ変数を宣言する.aspxが自動生成するパーシャルクラスの
>二つが作られるわけでしょ？
バージョンもWEBサイトかWEBアプリかも特定せずにメンバ変数を宣言するパーシャルクラスが自動生成されてるとか
パーシャルクラス（宣言のコード）なのにクラスが二つ作成されるとか
>コードビハインドは、そのメンバ変数を参照してる（からインテリセンスで補完してくれる）わけで
コードビハインドだと勝手にメンバ変数参照してるとか
メンバ変数参照してるからインテリセンスがきくとか
>メソッド内では決して参照しないまったく関係無いコントロールのインスタンスをメンバ変数として保持し、
必ず存在しているコントロールじゃない限り、一々FindControl(>120)って発言を無視してるとか
もうね、>>164のアンカーは自分に向けとけとしか
167:nobodyさん
09/09/22 14:17:50
不要なインスタンス云々を言ってる奴って、型付DataSetとか絶対認めない・使わないのかなｗ
コード内でDataColumnsを定義するのがﾒﾝﾄﾞｸｾｰって理由だけで型付DataSetを使うと、使わない
メソッドが腐るほど自動生成されるよね。それって無駄だから型付DataSetは使用禁止！ってル
ール？ｗ
168:nobodyさん
09/09/22 15:44:08
なんか急に関係ない話し始めたやつがいるぞｗ
169:nobodyさん
09/09/22 16:40:24
そもそもイミフな意見を、煽らんがために
エスパー解釈するから余計面倒なことになってるな。
170:nobodyさん
09/09/22 17:42:14
流れを読まずに質問してみる。
ASP.NETが生成するhtmlが30MB位になって、クライアントPCにダウンロード完了してから
実際にブラウザに表示されるまで30分ほどかかるんだけど、なんか上手い改善策ある？
サバーサイドの処理が重い訳じゃないので、どうしていいか分からなくて。
171:nobodyさん
09/09/22 17:59:03
30分ワロタｗ
画像含まずにhtmlだけで30MB?
いったいどんなシステムなんだよ。
ページ分けるしかないでしょ
必要な時に、必要な分だけしぼりこんで表示。
172:nobodyさん
09/09/22 19:32:16
>>165
>自動生成されたメンバ変数を使いつつ、コードを共有したいから、
>共通の基底クラスを継承するのではなく、コードビハインドを共有するんだろ。
逆だと思うのはコードの共有を目的とする観点からみてるから「逆」ってだけでしょ？
ページごとに、そのページが所有するコントロールの変数を
メンバ変数としてVisualStudioが宣言してるんだから、
VSつまりマイクロソフト的には1ページ1コードビハインド記述ファイルを前提ってことじゃないのってこと。
>パーシャルクラス（宣言のコード）なのにクラスが二つ作成されるとか
クラスが二つなんて書いてないじゃん。作文？
>必ず存在しているコントロールじゃない限り、一々FindControl(>120)って発言を無視してるとか
だから必ず存在している場合は、メンバ変数として宣言されてるからそれを参照できるわけでしょ？
ない場合があるからFindControlしてるわけで。
>メンバ変数参照してるからインテリセンスがきくとか
インテリセンスが聞くのは、コントロールをメンバ変数に宣言してるパーシャルクラスを
VSが自動生成してるからじゃないの？違うなら俺の間違いだな。すまなかった。
>もうね、>>164のアンカーは自分に向けとけとしか
>>164は俺じゃないよ
173:nobodyさん
09/09/22 19:35:00
やっぱそうだよなぁ。もはやページングしか残されてないよなぁ。
画像含まず、TextBoxとDropDownListとLabelとCheckBoxだけで構成されてるのに、htmlソース
で30MBとかいきます。ページングにすると更新のタイミングとかウザイんですよねえ。
俺ｵﾜﾀ
174:nobodyさん
09/09/22 19:41:58
>>166
>>メソッド内では決して参照しないまったく関係無いコントロールのインスタンスをメンバ変数として保持し、
>必ず存在しているコントロールじゃない限り、一々FindControl(>120)って発言を無視してるとか
それから例えとして書いてるのに、それを本筋に当てはめて見当違いのレスするのは止めようよ。
「クラスで例えれば～という感じになると思うんだ。」って書いてるじゃん。
そういうように書いてるぐらい「アホ」なやり方をしているっていうわけで、
そういうような仕組みでASP.NETが動いてるなんてかいちゃいないだろ？
>TextBox1,2,3があるページと、TextBox1,3,4があるページの両方が同じ分離コードをさしてる
>として、片方のページを表示してるとTextBox1,2,3,4のインスタンスが出来るとでも思ってる
>の？馬鹿なの？死ぬの？
これも同じ。だれも作られるなんて言ってないだろ？
メンバ変数で宣言されてるのにそれを参照しないコードの書き方がおかしいんじゃないのっていってんの。
つまり、おまえの批判はこういう的外れなことをいってるわけ。
酒井法子って覚醒剤やってたんだな・・・
これで逮捕されてもう芸能界じゃやっていけないだろ
↓
ほんとだな万引きで捕まったぐらい恥ずかしいよな
↓
お前バカじゃねぇ？酒井法子は万引きで捕まったんじゃねーよ。
ひょっとして万引きで捕まったとおもってんの？バカなの？死ぬの？
こんな感じ
175:nobodyさん
09/09/22 19:59:09
シルバーウィーク進行中
176:nobodyさん
09/09/22 20:18:47
>>172
クラス２個作られるのが俺の作文だっていうなら
>ロジックを記述するパーシャルクラス(ページなんちゃら.aspx.cs)と、
>コントロールなどのメンバ変数を宣言する.aspxが自動生成するパーシャルクラスの
>二つが作られるわけでしょ？
を解説してくれ
そして、
>必要ないインスタンスが生成されるのを「有り」とする人が多いのに驚いた
の必要ないインスタンスとは何か説明してくれ
177:nobodyさん
09/09/22 20:22:23
>>173
こないだの1000だか3000だか5000だかの
大量のコントロールを埋め込もうとしてた人?
178:nobodyさん
09/09/22 22:49:18
>>173
1000とか3000とか5000とかそんな桁じゃないんで違う人です。1桁違う。
5万コントロールとか10万コントロールとかそういう数なんで。
179:nobodyさん
09/09/22 23:41:39
もはや御愁傷様としか…w
180:nobodyさん
09/09/23 00:08:00
>>178
何をやってるのか、ぜひ教えてくれ。 面白そうだ。
30分かけて表示されたページは、まともに動くの？
あと、 >>172 >>176 メールでやれ。
181:nobodyさん
09/09/23 00:42:51
複数のaspxのbehind-codeが共有されてるのに拒否反応示す人が多いのに驚いた。
幾つかのProjを見てきたけど、使ってるところは多い。別に禁断の技とか行儀の悪い実装
と言うことも無く、現場によっては普通に使われるテクニック。まあ、有効な局面が限られる
と思うが。
ちなみに「VisualStudio様がデフォで作ってるんだからそれが前提」とか書いてるけど、VS
が吐き出した自動コードをあとから手で書き換えるとか、半ば当然だと思うが。VS様はそ
んなに柔軟でもないし、賢くもない。
182:nobodyさん
09/09/23 00:52:11
>>181
いろいろ書きたくなっちゃうのは分かるけど、もういいから。
183:nobodyさん
09/09/23 02:36:28
>>170
設計者氏ねとしか言いようが無いな
184:nobodyさん
09/09/23 04:15:41
ASP.NET AJAXでWEBアプリケーションを開発しています。
JQueryのリッチなUIも交えて、開発したいのですが、以下のSilverLightの例のように、
HTML要素クリック時、あるいは、JavaScriptのメソッドからCSファイルのC#の
メソッドを実行するようなことはできないのでしょうか？
URLﾘﾝｸ(www.atmarkit.co.jp)
当方、かなり初心者なので、無茶苦茶な質問をしているかもしれません。
185:nobodyさん
09/09/23 05:33:46
>>176
>を解説してくれ
クラスは一個
その一つのクラスのパーシャルクラスが2個
>の必要ないインスタンスとは何か説明してくれ
必要のないインスタンスは必要のないインスタンスだ
それ以上でも以下でもない
動作するからといって、1行ごとにSleep噛ますのは意味ないよな？
それと同じように、1行ごとに必要ないインスタンスを生成しても意味ないっていってんの。
換言すれば、「動作するからといって1行ごとにSleepいれるのをアリとする人が多いのに驚いた」でもいいぞ？
ただし技術的に問題ないって主張してる人は、Sleep噛ましても動けばokらしいよ
Sleep噛ましても問題ないぐらいだから、1行ごとに不必要なインスタンス生成するぐらい余裕で許容すると思うけどｗｗ
>>144に書いてある。
186:nobodyさん
09/09/23 05:53:29
>>184
HTML要素がOnClickイベントを持っていて、フックしてClientScriptを実行できるなら
一番簡単なのは、ポストバックイベントを発生させることのできるコントロールを設置して
それをJavaScriptで実行させるのが一番簡単。
例えばボタン、ハイパーリンクとかをObject.Click();すればいい。
必要ならスタイルシートで背景と同化させるとか、見えなくさせたり。
まじめにやるならこのへんで
URLﾘﾝｸ(msdn.microsoft.com)
187:nobodyさん
09/09/23 08:31:09
>>181
具体性の無いレスはいらないから
188:nobodyさん
09/09/23 15:01:49
メールでやらないなら、IDだしてやってくれないかな。NGすっから。
189:nobodyさん
09/09/23 16:01:00
>>185
いい加減空気嫁
190:nobodyさん
09/09/23 16:57:49
>>186
おお！！
まさに知りたかったことです。ありがとうございます。
ModalPopupExtenderのときもダミーコントロールを使用した経験がありますが、
結構ダミーとして使うことってあるんですね！！
191:nobodyさん
09/09/24 14:23:39
IEだと問題なくて、FirefoxだとLinkButtonを押してもPostBackされないのは、どこを直せば
対応出来ますか？
以前の案件ではIE/FF/Opera/Safari/Chrome全部で動いてたはずなのに、今作って確認したら
IEでしか動かない('A`
192:nobodyさん
09/09/24 14:39:55
>>173
データベースならDataSet、固定のデータならArrayを持ち回りすれば更新関係が楽になるんじゃない？
DataSet、ArrayはSerializableだったはずだったから、これをセッションで持ってて
これを元にページングして表示し編集させる。
最後に更新ボタンがあって、これをクリックすると、それまで編集されたデータを一斉に更新するとか。
つまりページングや編集は、セッションで持ってるデータに対して行って、
最後に更新ボタンを押した瞬間に、編集された行のみ必要なら整合性チェックして保存していくような感じで。
193:nobodyさん
09/09/24 14:41:20
>>191
まずLinkButtonだけを設置したテストページでポストバックしないかどうかをチェックして。
194:nobodyさん
09/09/25 11:15:43
要件で定義されてる上限まで行数増やしてページ表示させたら、ページ上のコントロールの
数が16万超とかマジでどんだけーｗ
12時間経ってもまだ入力出来る状態にならないｗ
>>192
ページングも案の一つだったんですが、グーグルクルムが思った以上に軽いんで、もしかす
ると「IEで重いようならクルム使ってね」で逃げるかも。
195:nobodyさん
09/09/25 12:17:35
>>194
どうしても大量のデータ一覧表示しつつ、ぽこぽこ書き換えたいなら、
１レコード毎の書き換えが可能ならば、表示はテキストのみにして、行のクリックかなにかで入力できる形にjavascriptで書き換えて、入力完了したら
行ごとにajaxかなんかで書き換えするようにするかなぁ。
196:nobodyさん
09/09/25 13:02:30
>>194
ASP.NET vs 人間、ストレステストのネタとして最適ですね。
197:nobodyさん
09/09/25 19:58:58
>>194
IEは</table>が来るまで描画しないと思うので、
全体を一つのtableで囲むのを止めたらどうだろう
そしたら送られてくるhtmlごとに上から順番に描画してくれると思う。
ASPのほうでも、その都度、ブラウザに送信するとかの設定も必要だったはず。
198:nobodyさん
09/09/25 20:31:25
>>197
一番外側に大きなTABLEタグがあって、それはもう削除し様が無いのです('A`
ところで、この巨大なGRID形式の入力ページを、最初は市販のコンポーネントを買って実現し
ようか迷ってたんです。Grea○CityのSPR○AD .NET3J
Repeaterでひたすら自分でクルクル輪姦してhtmlを生成するのとどっちがよかったんかなぁ。
初めて使うコンポーネンツで躊躇したのと、軽量シンプルなhtmlを吐き出すのはrepeater使用
時だろうという推測で結局コンポーネントは使わなかったんですが、実は使ってた方がレスポ
ンス向上してたのかなぁ。こればっかりは今でも分かりません。
199:nobodyさん
09/09/25 20:44:18
>>198
今は自前でResponse.Writeなりしてるってこと？
想像だけど、Repeaterのほうが遅いと思う。
何万件とかなら、どんなコンポーネントを使っても快適とかはないと思うよ。
数が変化するなら、アプリで作っても通信だけで相当な時間がかかると思うし。
こうなったら、エクセルに出力させて編集させて、
今度はCSVファイルをアップロードして登録とかにしたら？
200:nobodyさん
09/09/26 08:44:34
>>198
GrapeCityのサイトでデモ使ってみたことある？
うちでは超遅かったよ
201:nobodyさん
09/09/26 15:17:01
久しぶりにきたが
まだ大量のコントロール使ったときの話してるのか？
ところで、asp.net のワーカープロセス（aspnet_wp.exe）の更新がきてるが
修正内容がまだわからんな。
しばらくしたら KnowledgeBase に載るとは思うが。
URLﾘﾝｸ(support.microsoft.com)
202:nobodyさん
09/09/26 19:51:06
>>201
今ホットなのはコードビハインダー
203:nobodyさん
09/09/26 20:15:29
おまいら、ドメインモデルどうですか。
おいらはまだ勉強中なので、ドメインモデルが何かすらきちんと説明できませんが。
↓ASP.NETでやってる人もいますよ
ドメインモデル VS トランザクションスクリプト
ｽﾚﾘﾝｸ(php板:42番)
204:nobodyさん
09/09/26 23:49:54
asp.netでのドメインモデルってやりにくくないかえ？
WebServiceありのサーバサイドありのJavaScriptでドメインモデルってやってられねーって感じ。
更にAJAXなんて入ってきたら設計で死ねるｗ。
VirtualBoxのソースを読んでても思うけど「管理大変そう」ｗ。
205:nobodyさん
09/09/28 04:18:26
マスターページについて質問です。
ある子ページでのみ必要なcss, jsがあるのですが、
マスターページ自体をいじることなくインポート出来ないでしょうか。
マスターページのheadタグ内にcontentPlaceHolderを置くことで、
子ページからhead要素にアクセスすることは出来ましたが、
これだとビルドの度に警告が表示されて鬱陶しく感じます。
206:nobodyさん
09/09/28 08:03:54
マスターページを入れ子にするとか？
207:nobodyさん
09/09/28 09:14:36
警告を無視する。
CやC++の仕事の時は警告が1件でもあったらうるさく言われてたけど、C#は基本は警告無視。
208:nobodyさん
09/09/28 13:07:10
コードで.jsファイルインポートしても警告でるっけ？
ClientScriptBlockほげほげとかいうやつ
209:nobodyさん
09/09/28 17:14:16
>>205
>ビルドの度に警告が表示されて
普通にVS2008でマスターページ追加すると<head>の中に初めから
ContentPlaceHolder設置されてるんだが、どんな警告がでるんだ？
210:205
09/09/28 18:58:14 Nc4wliQp
VS2005無印 ASP.NET2.0ですが、
ContentPlaceHolderは不明な要素～みたいな警告です。
あり得ないタグを使った時と同じ内容だったと記憶してます。
家では環境構築してないので…すみません。
警告は無視する方向で行きます。
ありがとうございます。
211:nobodyさん
09/09/28 19:18:41
HtmlLink link = new HtmlLink();
link.Href = "StyleSheet.css";
link.Attributes.Add("rel", "stylesheet");
link.Attributes.Add("type", "text/css");
Master.Page.Header.Controls.Add(link);
212:nobodyさん
09/09/28 19:41:37
普通にこれ使えばいいんじゃないの？
URLﾘﾝｸ(msdn.microsoft.com)
マスターページを適用した一部のページだけなんだから、
その一部のページのコードビハインドファイルに記述すればいいじゃない？
213:nobodyさん
09/09/29 22:38:09
ListBoxでプルダウン選択したときに、Labelの値をViewStateから持ってきて変更したいのですが、
ポストバックしないで実装する方法はありますでしょうか？
214:nobodyさん
09/09/29 22:47:27
213です。
ListBoxではなく、DropDownListの間違いです。すみません。
215:nobodyさん
09/09/29 23:22:25
>>214
漏れはフルECMAscriptで実装しました。
MS的にはポストバックして欲しいみたいなのでオススメしない。
216:nobodyさん
09/09/29 23:34:57
>>213
ViewStateって何のViewStateなのかな。
HiddenFieldに格納した情報を、DropDownListのIndexをキーにClientScriptで取得して
Labelに表示すればいいような気がするけど。
217:215
09/09/30 00:15:29
>>216 見て気づいたがViewStateからは直接値取れないわ。謎のルールでエンコードされた文字列を解析せにゃならん。
Hiddenに書くのも癪だったので全部JSのArrayに定義して、ClientScriptに登録した。
218:nobodyさん
09/09/30 14:20:16
IISの稼動しているサーバーがActiveDirectoryに参加している場合
ASP.NETで統合Windows認証をすればActiveDirectoryに参加している
クライアントのみ受付可能ですか？
219:nobodyさん
09/09/30 19:48:28
213です。
やりたかったのは、DropDownListの選択値と一対一に対応する文字列をポストバックしないで
クライアントサイドで表示させたかったのですが、
とりあえず今日調べたところ、ViewStateを使うまでも無くDataTextFieldとDataValueFieldを使って
Labelの表示を変更することができました。
（DataValueFieldが一意の値しか認めないというバグを知らず、かなり悩みましたが・・・）
それでも、相変わらずポストバックは必要な状態で止まってます。
ClientScriptで取得して表示できるとの事ですが、具体的な実装方法を示したサイトなどご存知でしたら
教えていただけますでしょうか？
220:nobodyさん
09/09/30 20:41:22
あくまで例えばだけど、
<head runat="server">
<script language='JavaScript'>
function Change(obj) {
Label1.innerHTML = testArray[obj.selectedIndex];
}
</script>
</head>
<body>
<form id="form1" runat="server">
<asp:DropDownList ID="DropDownList1" runat="server" onChange="Change(this);">
</asp:DropDownList>
<asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>
</form>
</body>
</html>
221:nobodyさん
09/09/30 20:42:05
protected void Page_Load(object sender, EventArgs e)
{
int loopCnt = 1;
string clientScript = "";
while(loopCnt <11)
{
this.DropDownList1.Items.Add(loopCnt.ToString());
clientScript += "'"+loopCnt.ToString() + "',";
loopCnt++;
}
clientScript = clientScript.Substring(0, clientScript.Length - 1);
clientScript = "<script language='JavaScript'>var testArray = new Array(" + clientScript + ")</script>";
Page.RegisterClientScriptBlock("ClientScript", clientScript);
}
使っちゃいけないのを使ったり、汚いコードはご愛敬で。
222:nobodyさん
09/09/30 21:22:20
ListBoxに加えられた項目をアルファベット順に並び替えるにはどうすればよいのでしょう？
WindowsFormではSortプロパティがあるのですが、ASP.NETのListBoxにはありません。
一旦全部配列に抜き出して、並び替えた後に順番に追加していくしかないのでしょうか？
スマートな方法をご存知の方、よろしくお願いします。
223:nobodyさん
09/09/30 21:46:58
LINQでも使って並び替えるしかないんでないかな
ASP.NETは追加とかソートはポストバックしないとできないから、
コントロールにソートの項目がないのかもしれないね
224:215
09/10/01 01:12:00
>>219
Literalって変換されたらプレースホルダ無くなるよね。下の例はInputフィールドに適用する場合。
var script =
@" function updateField(v) {{ $get(""{0}"").value = v; }}"
String.Format()で0にInputフィールドのClientIDを指定、
RegisterClientScriptBlockで登録
DropDownListのOnChangeに上のfunction呼び出しをサーバサイドで登録。
updateField(this.options[this.selectedIndex].value)
OnChangeをクライアントサイドで登録する場合は$addHandlerでやらないといけない。
iphone で適当に書いてるから間違えてたらゴメン。
225:nobodyさん
09/10/01 01:41:28
>>219
どうしてもポストバックさせちゃダメなのか？
クライアント側のスクリプトすらすら書けるレベルないと、実装例みても
理解できないんじゃないかな
とりあえずUpdatePanelつかうと幸せになれるかもしれないぞ
226:nobodyさん
09/10/01 11:19:54
ASP.NETからOracleに接続する方法でOracleClient無しで
接続できるものはありますか？
例えばJavaのJDBCはJDBCドライバだけあれば接続できるので
そのようなものがあればありがたいのですが・・・
227:nobodyさん
09/10/01 14:54:33
>>226
パフォーマンスがいいかわからないけど
たいていのDBでODBC接続はできる。
oracleもたぶんodbcでつながるとおもうよ
ドライバも標準ではいっていたような
228:nobodyさん
09/10/01 15:03:06
ASP.NETって素晴らしいフレームワークだと思うんだけど
（一部のExtenderコントロールを除いて）
なんで？
229:nobodyさん
09/10/01 15:23:48
>>227
たしか標準のオラクルODBCドライバはオラクルクライアントが必要
JDBC以外でオラクルクライアントなしでつながる物はしらない
230:nobodyさん
09/10/01 16:18:31
へじﾀｿが優秀なんじゃね？
231:nobodyさん
09/10/01 16:41:38
>>227, 229
ありがとうございます。
やはりオラクルクライアントは必要そうですね。
232:227
09/10/01 18:17:30
>229 >231
ODBCはOpen DataBase Connectivity の略だし、共通の規格だから動くんじゃないの。
オラクルの商用製品ソフトウェアが必要なのは、オラクルのネイティブな接続では。
ODBCは準拠してる製品なら、どのDBでも接続できると思ったよ。
接続できないとOpenじゃないし。下のぐぐった結果みてもできそう。
URLﾘﾝｸ(e-words.jp)
ODBC
フルスペル ： Open DataBase Connectivity
ODBCとは、Microsoft社によって提唱された、データベースにアクセスするため
のソフトウェアの標準仕様。各データベースの違いはODBCドライバによって吸
収されるため、ユーザはODBCに定められた手順に従ってプログラムを書けば、
接続先のデータベースがどのようなデータベース管理システムに管理されている
か意識することなくアクセスできる。
233:nobodyさん
09/10/01 18:20:25
でもODBCの設定画面を開くとTNS名を入れろって言われるから
やっぱりオラクルクライアントが必要だと思う。
234:227
09/10/01 18:20:27
もういっこ検索結果を。
URLﾘﾝｸ(www.amy.hi-ho.ne.jp)
Oracleのサイトから落とせるODBCドライバでいけるそうな。
標準のODBCドライバとどう違うかは不明。
235:nobodyさん
09/10/01 19:09:47
ODBCってのは、アプリがDBを操作する方法をオープンな規格でやりましょう、って話だ
ドライバがDBと通信する方法を既定しているものではない
ODBCドライバが存在すれば、どんなDBでもODBC経由でアプリから接続できるってこと
236:nobodyさん
09/10/01 19:28:55
つまり
OracleはDBそのものがODBC準拠だからODBCドライバがあればいけるってこと？
それともOracleをODBCに準拠させるためにOracleが出してるODBCドライバが必要で、
さらにアプリ側にODBCと通信するためのドライバが必要ってこと？
237:nobodyさん
09/10/01 19:37:43
OleDBなら、接続文字列を変更するだけでSQL ServerもOracleもMDBも行けると思っていたのだけど、
認識間違ってますかね？
238:nobodyさん
09/10/01 20:27:54
>>236
オラクルが直接ODBC準拠じゃない
オラクルをODBCで操作するためには、オラクル用のODBCドライバが必要
オラクル製でもマイクロソフト製でも基本的にはアプリからの違いはない
ODBCと通信するんじゃない。（ドライバと）ODBCで通信するんだ
ドライバとアプリはODBCで通信する。ドライバとDBはDBごとのネイティブで通信する
オラクル用のODBCドライバなら、ドライバとDBとのネイティブ通信にオラクルクライアントが必要
これ以上はDB関係の板行って聞け
239:nobodyさん
09/10/02 20:02:27
>>238
つまり
何かのテクノロジ-->>(テクノロジとODBCが通信するためのドライバ)-->>(ODBC規格)-->>(オラクルにODBC接続を提供するドライバ)-->>オラクル
ってこと？
240:nobodyさん
09/10/02 20:52:19
GridViewの内容をExcelファイルに出力したいのですが、
URLﾘﾝｸ(www.atmarkit.co.jp)
のようなやり方で実現はできるのですが、Excelファイルの保存形式が、
純粋なExcelブック形式ではなく、拡張子こそXLSですが、中身はHTML形式？
みたいな保存のされかたです。
純粋なExcelブック形式のファイルとして出力するにはどうすればよいでしょうか？
ご教示願います。
241:nobodyさん
09/10/02 20:58:43
>>239
238も239もだいぶ間違ってる。
オラクルのネイティブなデータプロバイダはOracle Call Interface (OCI) を使ってアクセスする。
ODBCやOLEは別の古い規格。
.net frameworkにoracle用のデータプロバイダがあるんだからそれを使うのがベスト。
ODBCとかいまどき使う意味は俺にはわからない。
まずは質問しまくるまえにWindows SDKを読むこと。SDKのv6.1にはADO.NETの下に
Oracle and ADO.NETという項目がある。インストール後のURLでいうと
ms-help://MS.LHSMSSDK.1033/MS.LHSNETFX30SDK.1033/wd_adonet/html/8ee8e389-53cf-45cf-80bd-1df63ef34f2e.htm
web版
URLﾘﾝｸ(msdn.microsoft.com)
242:nobodyさん
09/10/02 21:21:46
どのみちオラクルクライアントが必要
243:nobodyさん
09/10/02 22:38:40
DLLコピーすりゃいいんじゃねえの
244:nobodyさん
09/10/02 22:57:37
>>241
いまさらODBC使う意味がないってのには同意するが、>238は別に間違ってもいないだろう
そして、.NETのオラクル用データプロパイダ使ってもオラクルクライアントのインストールは必要だぞ
245:nobodyさん
09/10/03 13:56:21
先日検証用にOracle Database 10g Express Editionを入れたのですが、
この時ODP.NETなんかも知らないうちにこっそり入ってきたと考えてOK？
246:nobodyさん
09/10/03 17:33:18
つまりOracleClientはOracleに接続するためのAPIセットだからインスト必要ってこと？
DLLのみコピーするとか手段の違いは抜きにして。
247:nobodyさん
09/10/03 18:52:54
そゆこと
248:nobodyさん
09/10/05 18:17:11
VWD 2008 SP1 で開発しております。
SqlDataSourceのデータソース構成ウィザードで
パラメタつきのストアドを選択し、パラメータの定義まで進むのですが
パラメータソースの部分にNone以外選択できません。
別マシンのSP1ではないVWD 2008だと普通にControlなどを設定できます。
VWDをインストールしなおした方が良いのでしょうか？
それとも何か私の方で足りない設定などあるのでしょうか？
249:nobodyさん
09/10/06 08:02:48
Web 開発会社のビジネスを支援する Microsoft(R) WebsiteSpark(TM) プログラムを開始
URLﾘﾝｸ(www.microsoft.com)
【参加要件】
・Web 制作や開発業務を主なビジネスとしていること（Web サイトなどで主業務が明確になっていることが必要）
・従業員数が25名以下であること
・Windows プラットフォームを用いた新しいドメインのWeb サイトの開発を積極的に推進すること（6ヶ月以内に1サイト以上構築）
※マイクロソフトのパートナープログラム「マイクロソフト パートナー ネットワーク（MPN）」へ未参加の場合、
WebsiteSpark への参加と同時にMPN にも参加が必要
【参加特典】
・マイクロソフトの Web 開発ツールやデザインツール
Visual Studio(R) 2008 Professional Edition 3 ユーザー ライセンス
Expression(R) Studio 3 1 ユーザー ライセンス
Expression Web 3 2 ユーザー ライセンス
・検証、デモンストレーション用途で利用できるサーバー製品※
Windows Web Server 2008 3 ライセンス
SQL Server(R) 2008 Web Edition 3 ライセンス
※：自社の環境で本番運用を行う場合は、
別途サービスプロバイダ向けのライセンス契約（SPLA 契約）の締結が
必要となります。ただし、Windows Web Server 2008 と
Microsoft SQL Server 2008 Web Edition について、
それぞれ 4CPU ライセンス分まで WebsiteSpark の参加期間（最大3年間）、
SPLA の費用は必要ありません。
250:nobodyさん
09/10/06 16:30:01
さてと、精鋭25名で分社するか・・・
251:nobodyさん
09/10/06 20:53:50
>>250
俺も仲間に入れてくれ。
252:nobodyさん
09/10/07 02:23:59
感覚の問題だしスレチなんだが、100人から25人とかだと精鋭って感じしないよな
1000人から25人だと精鋭だけど、100人とか200人から25人だと上位25名って感じ。
253:nobodyさん
09/10/07 08:36:48
おっと市場原理主義の悪口はそこまでだ
254:nobodyさん
09/10/07 14:01:32
大体、組織の5%位の人間が精鋭。
でも実際に本当に凄いのはその中のさらに5%くらい。
なので、真に精鋭と呼んでいいのは25%位しかいないと思う。
255:nobodyさん
09/10/07 14:19:06
>>254
算数大丈夫か？？0.25%だろ？？釣られてる？？
256:nobodyさん
09/10/07 17:08:27
5%×5%＝25%
257:nobodyさん
09/10/07 17:48:40
精鋭25人の方が本社だろ。
258:nobodyさん
09/10/07 18:17:55
>>257
ｗｗｗｗｗｗｗ
つ 座布団
259:nobodyさん
09/10/08 00:29:00
なるほど
100人中25人が本社の精鋭で、そのた75人のうち25人が分社時の精鋭と。
半分より上程度か('A`)
260:nobodyさん
09/10/08 09:10:25
動的コンパイルだけで動作させたいのでaspxファイルだけで
作りたいのですが、こんなのは異常ですか？
261:nobodyさん
09/10/08 12:29:29
別に
262:nobodyさん
09/10/08 17:17:31
インストール＝ソフト納品だから便利でいいじゃん
263:nobodyさん
09/10/08 17:22:47
クラスファイルとかはどうやってaspxファイルに取り込めばいいでしょうか？
<script runat="server" src="hoge.vb"></script>
とかださくないですか？
264:nobodyさん
09/10/08 18:47:41
>>260
WEBサイトで動的コンパイルさせたいだけならコードビハインドでもできる
普通はaspxにコードは書かないと思うが、まあそれで問題ないならいいんじゃない
>>263
App_Codeにソース入れておく
265:nobodyさん
09/10/08 19:21:58
>>264
すばらしすぎる。さんくす。
266:nobodyさん
09/10/08 22:14:09
GridViewのヘッダー固定について、これ！っていう手段が見つかりませんが、
皆さんのところでは客等からの要望ありませんか？
GridViewで表示させるテーブルが決まっているなら、むりやりCSSでフリーズ
させれば良いようだけど、いろんなテーブルをバインドするような可変の場合は
どうすればいいのかなぁ？
267:nobodyさん
09/10/08 23:32:35
>>266
金で解決する＝その手のコンポーネントを買う
268:nobodyさん
09/10/09 08:28:38
App_Codeって.NET Framework 2.0からなんですか？
.NET Framework 1.1には同じような機能はないでしょうか？
269:nobodyさん
09/10/09 09:16:33
レガシーASPのApplication.Lockがしたいのですが
ぬるぽが発生してしまいます。
何か間違っていますでしょうか？
Public Class Test
Public Sub test()
Dim hoge As New System.Web.HttpApplication
hoge.Application.Lock()
hoge.Application.UnLock()
End Sub
End Class