トップページ⇒php
983コメント422KB

【質問】ASP.NETスレ Part6【雑談】

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2009/09/01(火) 20:06:04ID:???
ASP.NETとは、マイクロソフトが提供するWeb アプリケーションと XML Web サービスを構築するための
Microsoft .NET Frameworkの一連のテクノロジの一つです。
技術の移り変わりの早い分野ですので、みんなで質問、相談しつつ、より理解を深めていきましょう。

●ASP.NET関連サイト
マイクロソフトASP.NETデベロッパーセンター
http://msdn.microsoft.com/ja-jp/asp.net/default.aspx
ASP.NETオフィシャル（英語）
http://www.asp.net/
VisualStudioホームページ
http://www.microsoft.com/japan/msdn/vstudio/
SQLServerホーム
http://www.microsoft.com/japan/sqlserver/2005/default.mspx
IISオフィシャル（英語）
http://www.iis.net/
ASP.NETにAJAX技術を取り入れるASP>NET AJAX（英語）
http://www.asp.net/ajax/
ASP.NETにMVCアーキテクチャを取り入れるASP.NET MVC（英語）
http://www.asp.net/mvc/
ASP.NETでのお役立ちの定番サイト
http://www.atmarkit.co.jp/channel/aspnet/aspnet.html

●前スレ
【質問】ASP.NETスレ Part5【議論】
http://pc11.2ch.net/test/read.cgi/php/1232671611/
0042nobodyさん2009/09/09(水) 07:28:11ID:???
>>40
>ASP.NET でやりやすいように設計するだけの話。それ以上でも以下でもない。
つまり顧客の要望であってもASP.NETでやりにくければ、そういう設計にはしないってことだな。
んー、自社向けなら許されるけど、納品する立場ならこんな発言許されないだろ。
プログラマ（というか設計者）として失格だと思うぞ。

>FormView を使わなかったらデータ項目とコントロールのやり取りを全部手で
>書く必要があるし、SQL も泥臭く書くことになるんじゃないの?
それのどこが問題なの？
求められる要求に対して、これらのコントロールが活用できるならすればいい。
しかし、そのコントロールを使わないと面倒で泥臭くて嫌と考えたり、
ましてASP.NETでやりやすいように設計するなんてのは本末転倒。

それに、ASP.NETが開発効率を上げるための仕組みだ。
結果、副次的にコードの記述が少なくなるところまでは理解できるが、
だからそういったコントロールを使わなきゃいけないと思うのは完全に間違いだろ。
あくまで利用できるところにのみ利用し、難しいところは基本的なコントロールで代替する。
ASP.NETは、基本的なコントロールを利用するだけでも開発効率は十分に高い。

>俺にとってはそっちのほうが面倒なんだけどな。
俺が思うプログラマが決して言ってはいけない言葉。それは「面倒」。
0043352009/09/09(水) 07:45:19ID:???
>>36
うちはMSSQLだわ。
DBMSからメタデータが抽出出来るなら動くと思うが、ムリぽいな。
0044352009/09/09(水) 07:52:48ID:???
>>42
すれ違いになるが、その「面倒」はこの先納品した客も被る訳だ。面倒を顧客の要望だからと言ってただ言いなりに実装するのは、自分にも顧客にも良い結果にはならない。
まあこういうフレームワークは日本の箱庭的システムにはそぐわないかもね。
0045232009/09/09(水) 08:04:03ID:???
>>41
俺のところだと SQL 手書きが発生するのは全体の 2 割以下だな。それもこれも最新の
ASP.NET が使えるおかげ。

>>42
わかった。お互い別の道を歩もう。
0046nobodyさん2009/09/09(水) 08:57:27ID:???
なんか、手段と目的が逆転してる人がいるよね。
0047nobodyさん2009/09/10(木) 09:08:58ID:???
ASP.NET（Frameworkは2.0）でWEBサイト開発して配置用にインストーラーを作った。
インストール先のサーバーにはFrameworkが1.1と2.0が入ってて、規定のサイトのASP.NETは1.1に設定されている。
この場合配置されたサイトは1.1で動作するようになってしまうんだが、インストーラー側で2.0に切りかえれないものだろうか？
配置後に手動で切り替えれば済むことなんだけど、なんとかならないかな。
web.configのsupportedRuntime要素を設定してもダメみたいだし。
0048nobodyさん2009/09/11(金) 03:46:12ID:???
>>44
FormViewを使わないことで面倒なら、もう何もしないほうがいいな
0049nobodyさん2009/09/11(金) 03:52:35ID:???
つーか、その面倒解消のためFormViewを導入しようとして逆に効率落ちてるじゃん
本末転倒
0050nobodyさん2009/09/11(金) 08:22:52ID:???
つか正直ASP.NETって帯に短し襷に長しだよな
0051nobodyさん2009/09/11(金) 16:36:40ID:???
>>50
その評価はまちがってる
ASP.NETが中途半端なんじゃなくて、用意されてるコントロールが中途半端なんだよ
0052nobodyさん2009/09/11(金) 18:15:27ID:???
>>51
中途半端じゃないとコンポーネント屋が困るからな
0053nobodyさん2009/09/11(金) 19:07:44ID:???
コントロールは、基礎的なものさえあればいいんじゃないのかな。
応用的なの作っても、結局特定の用途向けみたいな感じで、
万人向けじゃなくなっちゃうし、
かといってカスタマイズがこんだけできるんですって作ると、
今度は複雑になって逆に万人向きじゃなくなる感じがする。
今までで困ったのは帳票ぐらいかな。
こればかりは買ったぞ。数十万とかで。
あとはrepeaterさえ攻略すればなんとかなる感じ。
ところでformviewが話題になってるけど、
外部制約とかの整合性制約がある場合も対応できるの？
商品名を選択させてIDを入れるとか、
重複しない商品コードを入力させるとか。
試そう試そうと思っているうちにそのままなんだ。
0054nobodyさん2009/09/12(土) 13:14:52ID:???
俺、コントロールをポトペタする派なんだけど、
登録フォームをどうやってFormViewで作るの？
何かしらバインドしないとFormViewって表示されないよね？
0055nobodyさん2009/09/12(土) 17:18:05ID:???
よーし、ちょっとテストしてみようかな
0056nobodyさん2009/09/12(土) 23:04:00ID:???
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内にコントロールがあって、
それを選択可能？

うーむネットでも情報が少ないし疲れたよﾏﾏﾝ
0057nobodyさん2009/09/12(土) 23:54:01ID:???
子が親のIDもってるんじゃなくて、親が子のIDもってるのか？
それだと親と子は１：１にしかならないような

１）
置換するの意味がわからん
普通に結合するなりなんなりでChildCodeの項目も用意するだけでは？

２）
実行制御って具体的に何のこと？
DBへの排他制御なら、基本的に楽観的ロックなのでDBへのロックはなしだろ

４）
子テーブルの行数増えても親テーブルにもってるIDで見るだけじゃないのか？
お前の考えてる入力イメージがまったくわからんぞ
0058nobodyさん2009/09/13(日) 00:13:12ID:???
>>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なりに商品コードとして入力したいこととかない？と思って。
そんでその方法がよくわからんと。
0059nobodyさん2009/09/13(日) 00:45:56ID:???
なんか楽しそうだな。俺も後で参加しよう。
0060592009/09/13(日) 02:44:02ID:???
何回読んでもいまいち意味が分からん。
0061nobodyさん2009/09/13(日) 02:59:49ID:???
>>60
具体的に書けばいいのかなｗ

１）
textBoxに商品コードを入力させ、
その商品コードから商品テーブルの商品idを取得して、
商品idを受注テーブルに挿入することはformViewでできる？

２）
１）と似たような感じで、
商品コードをlistBoxから一覧で入力させるとき、
受注テーブルは楽観的ロックでいいけど、
商品テーブルは商品コードを入力中に、
裏で誰かが商品マスタを編集して商品コードを変更させてしまっても
楽観的ロックで排除してくれる？

３）
２）で楽観的ロックで確かめられないとしたら、
商品テーブルから商品コードと商品idが一致するのか確かめなくちゃだけど、
商品テーブルの商品コードの存在を確かめる→受注テーブルに挿入するの間に
商品コードが編集される可能性があるから、トランザクションで管理できる？

４）
textBoxに商品コードを入力させるとき
他のウィンドウや他のformから商品コードを検索して
formView上のtextBoxに入力させることはできる？

こんな感じなんだぜ。うぇーはっはっは
0062nobodyさん2009/09/13(日) 05:09:22ID:???
>>61
とりあえずFormViewの仕事とDataSourceの仕事を区別しよう

FormViewで出来るかと言われれば、全部出来る
コードレスで出来るかというなら、FormView周りにかぎれば、
条件つきでたぶん出来る（４以外）

お前が望むような動作をするDataSourceがあれば、って条件だがな
0063592009/09/13(日) 08:56:53ID:???
1)
できる。FormView関係ない。
2), 3)
個人的にコードレスではできないと認識している。
（2.0しか知らないから、今はどうなのか知らん）
4)
できる。FormView関係ない。

寝る。途中で飽きた。
ttp://www1.axfc.net/uploader/Sc/so/36159.zip
0064nobodyさん2009/09/13(日) 17:58:37ID:???
さんくす
FormView(+ObjectDataSource)は使うけど、
結局、相当に長くコードを書くのが必要なんだな。
コードみて大まかなやり方がわかったよ。ありがとう。

クエリを書くのが2割になったというので興味があったんだけど、
テーブルってほとんど他とリレーションしてるから、
結局は更新時にチェックをしなくちゃいけないよね。
そうすると何かしらのクエリの記述が必要になりそうだね。
既存のプロジェクトを調べたら、子テーブルのIDを持ってないテーブルって、
都道府県マスタとか、商品種別のマスタとか、一部のマスタぐらいしかなかった。
だから2割になるというより、最大で2割ぐらい減るのかなという印象。
これなら、無理してformView使うよりも
コントロールのポトペタのほうが、制限が少なくていいかなぁと思ったんだけど、
どうなんだろう。もちろん自分の場合の話だが。

ところで、文章から、2)と3)なんかを
FormViewで実装した経験がないように見受けられるけど、
そんなチェックはしないことが多いのかな？
整合性で問題がでるパターンが想像できると思うのだけど。
それとも、子テーブルのIDを持つようなテーブルを
更新したり、挿入したりすることがあまりないような
シンプルなサイトの開発が多いのかな？
ちょっと気になったもので。
0065nobodyさん2009/09/13(日) 18:44:22ID:???
親が子のIDをもつ親子関係ってのが理解できん
それで親と子が１：ｎになるんだよな？

通常の業務で入力するような範囲で、マスタの変更チェックなんてしないとおもうが
おまえのとこはそんなに頻繁にマスタが変更されるのか？
0066nobodyさん2009/09/13(日) 21:14:34ID:???
>>65
第一に、前者と後者は関連性はないよね。
n:nでも、n:1でもチェックが必要なのは同じことだから。確認のため。

1:nの関係はよくあると思うよ
商品->商品種別、会社->都道府県、支社->社員、会社->担当、受注->明細とか

親->子の例は、
そんな確認ができるのかなという疑問に思っただけなのと、
他のテーブルの主キーを持っていないテーブルが、
マスタ関連だけだったというだけなんで、
常にマスタのチェックをしなきゃいけないということを、
言いたかったわけじゃないんだ。ごめんよ。

でも、自由入力させる場合の商品コードは、
その存在チェックと主キーへの変換は必要だよね？
入荷した商品の、在庫の引き当て数量チェックとかも。
似た動作をいろいろ見ると、いろんな確認が必要で、
他のテーブルの確認をせずに、
無条件で更新できるような入力箇所って
思うより少ないのねって思ったの。んでもって、やっぱり手書きなんだなと。

掲示板とか、ゲストブック的な、
他のテーブルを意識しなくても済む単純な入力や編集には
便利だと思うんだけど
0067592009/09/13(日) 21:35:45ID:???
一応言っておくけど、俺はコントロールポトペタ派。

>そんなチェックはしないことが多いのかな？
登録対象商品がまだ有効かどうかのチェックはする。よくする。
ただし、普通、マスタの更新（UPDATE）なんてしない。ありえない。
やるなら削除後に新規登録、または新規登録のみ。
そうすれば登録対象が急に別物にすりかわるなんてことはなくなる。

1:nの関係はもちろんよくあるが、親が子のIDを持つことはありえないと思うんだが。
支社テーブルは社員IDを全部持ってるの？各社員（子）が支社コードもってればよくない？
0068652009/09/13(日) 22:27:45ID:???
>>66
１：ｎの関係はよくあるが、親が子のIDもった状態でどうやって
親：子が１：ｎの関係を作れるんだ？
その親に対する子はその親がもってるIDの子１件だけだろ
まさか同一IDの子が複数いるとか言わないだろうな

後半に関しては、個人的意見だがIDとコードを両方持つ設計は少ないと思うぞ
データとしては入力されるコードを格納すればいいんだし
コードとID別持ちで、コードからID引いて格納するって設計がまあ特殊なんだと

在庫引当の例とかは、ビジネスロジックとしてのチェックの問題だ
ビジネスロジックをコードレスなんてもともと無理だと思うがな
それは更新の問題じゃなくて入力内容チェックの問題
FormViewだろうがなんだろうが画面を表示する機能に直接関係ない
0069nobodyさん2009/09/14(月) 05:04:37ID:???
>>67
>登録対象商品がまだ有効かどうかのチェックはする。よくする。
するよね？
するってーと、ObjectDataSourceなんかでチェックして、
だめなら、だめの返値返して、エラー表示する処理とかになるよね。

>1:nの関係はもちろんよくあるが、親が子のIDを持つことはありえないと思うんだが。
>支社テーブルは社員IDを全部持ってるの？各社員（子）が支社コードもってればよくない？
ごめん。急いで書いたので、一部、不適切な関係があるね。
というか、自分が、どうやら、親と子を逆に捉えてるのかな。
他のテーブルの主キーを持ってる方を親だと、ずっと思ってたよｗｗ
商品マスタ->商品区分マスタ、取引先->都道府県マスタ、社員マスタ->支社マスタとか。
0070nobodyさん2009/09/14(月) 05:11:29ID:???
>>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を使うメリットってなに？
という話になるとおもうんだけど、
上のサンプルみると、各コントロールのインスタンスからデータを取得してるから、
ポトペタするのと変わらないようにみえる。
フィールド値のバインドを自動的にやってくれるぐらい？
という感じがしてるんだけど、という感じ。
うーん、なんかいまいちよくわかんないな・・
0071652009/09/14(月) 10:05:53ID:???
入力チェックは確かに必要だが、それは画面表示の機能(=FormView)の範疇でも
DB更新の機能(=DataSource)の範疇でもない（入力チェックをObjectDataSourceでやるのは
俺は間違ってると思う。DataSouceのもとになってるクラスでチェックするべきだと）

で、SQLの手書きが２割以下ってのは、俺は言いすぎだとは思う
ただ、純粋にSQLを書くという作業に限ってみれば、SQL書くところすべてに
SQLDataSourceつかえば、確かに自分でSQL書くことは少ないとはおもうが
それはアクセスでクエリビルダ使ったらSQL手書きしなくていいです、ってレベルと同じ話
必要なSQL文の数が減るわけじゃなくて、それを書く作業が減るだけ

DataSource使わないFormViewのメリットなんてないと思う。というか
FromViewはDataSource前提に設計されたコントロールだと思うが
DataSourceつかうことにメリットがあるんじゃなくて、使わないことにデメリットがある
0072nobodyさん2009/09/14(月) 19:50:49ID:???
>>71
DataSourceの元になるクラスという？
こういった場合にはObjectDataSourceでSELECT、INSERTなどのクエリを生成して、
コントロールにバインドするんじゃないの？
0073nobodyさん2009/09/14(月) 19:52:33ID:???
DataSourceの元になるクラスという？
↓
DataSourceの元になるクラスというと？
0074232009/09/14(月) 21:41:06ID:???
>>71
入力チェックは aspx.cs の仕事だと思うがなぁ。SQL 手書き 2 割以下というのは
ObjectDataSource で TableAdapter を使うパターンが 8 割を占める、という意味。
たとえ複数テーブルの更新が発生したとしても、内部的には TableAdapter を使い
回す。手書きが必要なのはバッチ処理ぐらい。まあ、プロジェクトにもよるがうちは
テーブル数と画面数が大体 200 ぐらいだな。コードマスタが 50 以上あったはず。
0075nobodyさん2009/09/14(月) 23:51:43ID:???
んー、確かにTableAdapterでいける部分は使うべきかな…。
うちは今一切使わない方針だけど。

なんかたまにASP.NET本来の原初的な組み方をしなきゃならないって考える波がくる。
で、MS本読み直すと「あー間違ってたのかな」と思ったり。
「Javaから来たヤツは全てを自前クラスで用意しようとする。
そうする利点は認めるがASP.NETでは…」みたいな論調だし。

で、軽く組み直してみたら、やっぱりハマるんだけどw
0076nobodyさん2009/09/15(火) 00:04:23ID:???
Dataの引っ張り方は人それぞれだから別とすると、
それならDataSourceと切り離してFormViewだけのメリットって何？
って話だな？

これとは別にTableAdapterを使うのはいいけど、データのソートとか抽出とかはどうしてる？
クエリかかないならTableAdapter.Fill(DataTable)して、DataTable.Select("")してるってこと？
これだとSQLからデータ抽出して、メモリに蓄えて、そこからまたSelectして
無駄が多いような気がするんだが。
0077nobodyさん2009/09/15(火) 02:15:05ID:???
結局のとこ、SQLを手書きする量が減るだけで、SQLの量そのものが減るわけじゃないってことだな
SQL書く作業がTableAdapter定義する作業になっただけ

昔のADO.NETでは、DataAdapterでのUPDATEは使えねえってのが定説だった気がするが
TableAdapterになって使いものになるようになったのかな？
0078nobodyさん2009/09/15(火) 03:43:03ID:???
ただ全部の項目を埋めて、挿入、更新するだけなら結構使える
複雑なことしようとすると、TableAdapter用のクエリの手書き必須
挿入時に論理削除を意味するIsDeleteをいじられたくないのでfalseで固定したいとか
サブクエリで抽出した内容を取得して挿入したいとか。
挿入したときの主キーを取得するのも手書きが必要だったような。

あと上にもあるけど動的にクエリを発行できないので
検索条件に従ってWhere句を作成するとかは無理だったはず。
かといってDataTableのSelectメソッドをWhere句の動的生成の
変わりに利用すると、いちど全部のデータを取得するので、
行数が多いとデータの取得に時間がかかる。

そのたありがLinqToSQLやEntityFrameworkで解決してると思うんだけど、
LinqToSQLは終了の方向だし、EFもなんとかしてくれって言う人が多くて、
まだ微妙なところ。
0079232009/09/15(火) 07:39:06ID:???
>>76
うちでは Excel の仕様書から TableAdapter を自動生成していて、SelectList メソッド
にソート引数も指定できるようにしてるよ。内部的には ORDER BY に変換する。

>>77
やっかいなのは、SELECT するのは VIEW だけど更新もしたいケース。そんな時は
Update メソッドの中で、個々の TableAdapter を使い回す。それで対応できなければ
SQL 手書き。

>>78
WHERE の動的作成は頻出パターンなので、TableAdapter の自動生成時に作り込んで
いる。つまり、検索条件を引数にもらう SelectList メソッドの中で、引数が null じゃ
なければ WHERE に追加している。こうすると、画面側では検索条件をバインドする
だけで済む。
0080nobodyさん2009/09/15(火) 17:37:59ID:???
>>79
>TableAdapter を自動生成していて
>WHERE の動的作成は頻出パターンなので、TableAdapter の自動生成時に作り込んで

それでSQL手書きが２割以下になるのか。それなら納得
しかし、自動生成されたSQLを使うのはどうもあまり乗り気になれん
TableAdapterにしてもDataSourceにしても、SQLは完全にラップされて
アプリ側から見えなくしてるわけだし、その方向が正しいのはわかるんだけど

アプリ側でSQLもシームレスに使いたいっていうと、LINQな方向に行くのかねぇ
でもあれもSQLがそのまま通るわけじゃないしなぁ
0081nobodyさん2009/09/15(火) 19:25:00ID:???
>>79
>TableAdapter の自動生成時に作り込んでいる。
>つまり、検索条件を引数にもらう SelectList メソッドの中で、
>引数が null じゃなければ WHERE に追加している。
これどうやるの？
TableAdapterで、条件に従ってWHEREを追加とかできたっけ？
0082nobodyさん2009/09/15(火) 23:02:34ID:???
Yのつくとこがすきそうな手法だな・・
0083nobodyさん2009/09/15(火) 23:29:57ID:???
自動生成時に作り込む＝クエリビルダでクエリを作る＝細かいところは手書きでクエリ修正
とかじゃないだろうなｗ
0084232009/09/15(火) 23:52:09ID:???
>>81
Excel マクロでコード生成するんだからパターンさえ決まれば何でもできる。
Fill 系のメソッドで引数チェックして WHERE を組み立てるなんざどこでも
やってることでしょ。
0085nobodyさん2009/09/16(水) 01:27:00ID:???
>>84
そのFillなんちゃらの引数によって、クエリを作ったりできたっけ？
自分はできないと思っていたので、できるのなら教えてほしい。
環境はVS2005+SQLServer2005
0086nobodyさん2009/09/16(水) 01:32:33ID:???
途中で送信してしもた
環境はVS2005+SQLServer2005で、TableAdapterのFillなんちゃらのメソッドで、
引数に従ってWHEREを作成するなんて無理だと思ってた。
Fillなんちゃらがストアドを呼び出してて、
ストアド側で引数によってクエリのWHEREを組み立ててるならわかるけど、
それはクエリを書いてるから手書きクエリの削減じゃないしなぁ。
0087nobodyさん2009/09/16(水) 06:02:19ID:???
>>84
>Fill 系のメソッドで引数チェックして WHERE を組み立てるなんざどこでも
>やってることでしょ。
Fillなんちゃらって、TabelAdapterのか？
SQL指定したらメソッドの中身はウィザードで勝手に作られてるぞ
すくなくとも自分でコードは書いてないから、動的にSQL作ったりはしてない
これをいじるぐらいなら俺ならTableAdapterなんて使わん

>>86
実現させる方法をいろいろ考えたが
部分クラスか継承させたクラスでFillなんちゃらを全部自前で実装すればできそう
SelectList メソッド ってのもよくわからんし、自動生成されてるのは
TableAdapterだけじゃないのかもしれんが、そのへんは>84じゃないのでわからんｗ

たとえストアドで操作してても、そのストアドが自動生成されているなら
「手書き」クエリは減ってるとは言える

まあ、なんかしらの開発用フレームワークあるんじゃないかって感じだな
0088232009/09/16(水) 07:26:21ID:???
>>86,87
TableAdapter は Excel の仕様書からマクロで自動生成してるんだって。Fill とか
SelectList とか名前はどうでも良くて、要するに ObjectDataSource の Select
メソッドに選択できるメソッドの中で、引数をチェックして WHERE を組み立てる
ロジック込みで、コードを自動生成している。TableAdapter をウィザードで作って
いるわけではない。これを「手書き」と思うなら、まあどうぞ御自由に。
00891552009/09/16(水) 16:20:34ID:???
>>88
すまん、どの引数なのか、ウィザードとは何のことかさっぱりわからん。
よければ質問に答えてくれないか？

>ObjectDataSource の Selectメソッドに選択できるメソッドの中で、
>引数をチェックして WHERE を組み立てるロジック込みで、コードを自動生成している。

Ｑ１　どの引数をチェックしてWHERE文を作成してるの？
１．ObjectDataSourceのSelectメソッドの引数
２．TableAdapterのFillなんちゃらメソッドの引数
３．その他のメソッドの引数（どのメソッド？）

Ｑ２　WHERE文を組み立ててるのはどこ？
１．ObjectDataSourceのSelectメソッド
２．TableAdapterのFillなんちゃらメソッド
３．Excelのマクロ
４．その他（どこ？）

Ｑ３　自動生成するクエリの範囲は？
１．すべてをExcelのマクロで作成
２．WHERE文以外をExcelのマクロで作成、WHERE文のみQ2のメソッドで、Q1の引数から作成
３．すべてをQ2のメソッドで、Q1の引数から作成
４．その他（どこ？）
0090nobodyさん2009/09/16(水) 16:21:32ID:???
失礼、名前は無関係
続き

>TableAdapter をウィザードで作っているわけではない。
Ｑ４　TableAdapterそのものはどうやって作ってるの？
１．データセットデザイナ
２．その他（なに？）

Ｑ５　作成したWHERE文から前のクエリとWHERE文はどこに登録してるの？
１．すべてのクエリをTableAdapterに登録
２．WHERE文から前をTableAdapterに登録、WHERE文はDataTable.Selectメソッドで登録
３．その他（どこ？）

Ｑ６　クエリをどこに登録してるの？
１．拡張子.xsdのxmlファイルのに手書きで作成したクエリを追加
２．データセットデザイナのクエリ構成ウィザードを使って作成したクエリを登録
３．データセットデザイナのクエリ構成ウィザードからクエリビルダを使って作成したクエリを登録
４．その他（なに？）
0091nobodyさん2009/09/16(水) 16:35:02ID:???
データアクセス層のクラスを自動生成するって話はわかるんだが
その自動生成されてるものはTableAdapterといえるのだろうか
そもそもTableAdapterって何だって話になるんだが、MSDNによると
>TableAdapter は、DataAdapter の機能を向上させるためにデザイナで生成されるコンポーネントです
らしい。
当然TableAdapterと１００％互換のあるクラスも作成可能なんだろうが
それを生成したからといってTableAdapterを自動生成っていうと誤解を招くとおもうな
ObjectDataSourceでの使用が前提なら、あえてTableAdapterと互換のあるものにする必要もないし

SQL手書き量が減ってる最大の要因はこのデータアクセス層クラスの自動生成のおかげで
けっして最新のASP.NETのおかげではないってのも誤解を招いた原因の一つだな
0092nobodyさん2009/09/16(水) 18:30:04ID:???
いや、既存の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使えばソートやフィルタリングはできるが、これもクエリの動的発行じゃない
0093232009/09/16(水) 21:41:11ID:???
>>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 も)は
いいぜ、という程度のノリだった。すまんかった。
0094nobodyさん2009/09/16(水) 22:11:35ID:???
　　　　　　　　∧∧
　　　　 　　ヽ(･ω･)/　 　ｽﾞｺｰ
　　　　 　＼(.＼ ノ
　　　　､ﾊ,,､　￣
　　　　￣

でDataSourceと関係なく、FormViewのメリットってなに？
本来、ポトペタするコントロールに、フィールド名を登録するだけでバインドしてくれるところ？
0095nobodyさん2009/09/16(水) 22:50:54ID:???
なんと比べてのメリットって話もあるが、1.1と比べるなら
FormView(DetailsViewも）のメリットは、データソースの単一レコードにバインドでき
レコードのナビゲーションを操作する機能まで取り込まれているところがメリットかと
1.1で単一レコード表示させたら、レコード移動と画面の更新を全部自分でやらんとダメだからな

双方向バインドで自動更新なんておまけみたいなもんですよｗ
0096232009/09/16(水) 23:02:19ID:???
>>94
それもあるが、レイアウトを自由にカスママイズできるってのと、あとは登録処理が
FormView.InsertItem(false) で OK なところとか、Update の時に元々の入力値も
引数で一緒にもらえるところとかね。使ったことないなら使ってみたら?

>>95
ナビゲーションは逆に使ってないな。GridView との連動パターンしかない。
それと、双方向バインドで自動更新は不可欠だろ! これのおかげでどんだけ楽に
なってるか。
0097nobodyさん2009/09/16(水) 23:33:22ID:???
本当に日本語が不自由な奴だな

>レイアウトを自由にカスママイズできるってのと
レイアウトの自由度はポトペタ>>>>>>>>>>>>>>>>>>>>>>>>(越えられない壁)>FormViewだろ？
なんでレイアウトの自由度がポトペタに対してFormViewのほうがメリットあるんだ？
>あとは登録処理がFormView.InsertItem(false) で OK なところとか、
そんなのFormViewじゃなくても作り方次第
>Update の時に元々の入力値も引数で一緒にもらえるところとかね。
そんなのFormViewじゃなくても作り方次第

>それと、双方向バインドで自動更新は不可欠だろ! これのおかげでどんだけ楽になってるか。
多くの人はなってないんだよ。
おまえだけがエクセルでやってるから楽なの。

FormViewの利点を述べたいがために強弁してないか？
ASP.NETでクエリを書くのが2割になったとか、
レイアウトを自由にカスタマイズできるとか、
作り方次第でどうとでもなることをFormViewのメリットだと述べたりとか、
自分がやっている方法に固執してFormViewは便利だと述べたりとか。
0098232009/09/17(木) 00:05:04ID:???
>>97
作り方次第のところはそう言うならまあ頑張ってくれやって感じだが、双方向バインド
は Excel とは何の関係もないよ。
0099952009/09/17(木) 01:07:19ID:???
>>96
>レイアウトを自由にカスママイズできる
レイアウトのカスタマイズなんてFormView以外でもカスタマイズできる
これはFormViewのメリットでも何でもない

>ナビゲーションは逆に使ってないな。GridView との連動パターンしかない。
ナビゲーションの真意が伝わってない気がするな。FormViewでレコードを移動するって話じゃないぞ
レコードが移動されたときに新しいレコードにバインドし直すって話だ
いちど、FormViewつかわないで一覧からカレント行取得して詳細表示するコード書いてみ
このコードを自動でやってくれるのはかなり楽
データ更新は、SQL書くのなんてパターン決まってるから難しくはない
（それこそ自動生成で８割まかなえるほどに）
ただ、ビジネスロジックのチェックはそうはいかんし
単純な更新でないと使えないってのが感想だ

>>97
作り方でどうにでもなるのはその通りなんだが、問題はその作りこみが
FormViewで不要や楽に実現できるようになるかどうかだろ

レイアウトの件はまあ同意だが、FormViewにもポトペタすればある程度自由にできるぞ
登録処理は、単純な更新に限れば楽なる
UPDATEの元値は、DataSet使わないならかなり有効な機能だと思う

1.1には単一レコードを想定したバインドコントロールはないんで、
その点でFromViewにはメリットはあるから、使えるとこなら使えばいいかと
逆にデメリットは、自由度が下がるってことか
それでもある程度コードかけばカバーできる範囲だと思う
0100nobodyさん2009/09/17(木) 05:26:24ID:???
>>99
上のほうにナイスなたとえがあるけど、まさにその通りだと思ったな
FormViewは麺つゆ
ウドンやソバを作るのには便利だし美味しい
だけどいくら加工してもベースが麺つゆだから味が似てしまう（応用度が低い）し
麺つゆだから酢醤油や砂糖醤油にはならない。
ポトペタの醤油は手間はかかるがより多くの料理に利用できる。
こんなとこだろ
0101nobodyさん2009/09/17(木) 10:42:52ID:???
ウェップフォーム上の全チェックボックスのチェックをオフにしたいんですが、方法は
ありますでしょうか？repeaterの中にあってIDが固定じゃないのでべた書きすることが
出来ません。
0102 [―{}@{}@{}-] nobodyさん2009/09/17(木) 12:15:57ID:???
>>101
サーバ側でならRepeater.ItemDataBound イベントで処理する。
クライアント側でならJavaScriptで走査して処理する。
0103nobodyさん2009/09/17(木) 15:36:36ID:???
チェックボックスOFF程度でバインドし直すのもな。
俺ならサーバー側もforeachで回す。
0104nobodyさん2009/09/17(木) 16:26:00ID:???
なにをみてforeachで輪せばいいんですか？
0105 [―{}@{}@{}-] nobodyさん2009/09/17(木) 17:23:14ID:???
>>104
Repeaterの中をIDでFindControl
0106nobodyさん2009/09/17(木) 23:30:47ID:???
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);
        }
    }
}
0107nobodyさん2009/09/18(金) 05:33:22ID:???
type='reset'なhtmlボタン配置したらどうだろうか

まあ俺なら、ページ出力時にクライアントサイドのスクリプトを動的に生成して出力しとく
チェックボックスオフにするためだけにポストバックさせたくない

今ならAjaxでやるのもありなのかもしれん。updatepanelだっけ？
その場合、Repeaterの中全部更新されるよね？
0108nobodyさん2009/09/18(金) 09:52:05ID:???
>>107
CheckBox以外のControlsもあったらどうすんの？
0109 [―{}@{}@{}-] nobodyさん2009/09/18(金) 10:44:13ID:???
>>107
JQueｒyとか使うと楽ちんだわな
0110nobodyさん2009/09/18(金) 15:09:35ID:???
>>108
その場合はその項目もリセットされるわな
それがまずいかどうかは>101の判断だろう
まあ、一番楽な方法としてリセットボタン考慮する価値はあるかと
0111nobodyさん2009/09/18(金) 15:15:51ID:???
>type='reset'なhtmlボタン
そういえばそんなのもあったな。すっかり忘れてたわ。
0112nobodyさん2009/09/18(金) 19:03:46ID:???
俺もClientスクリプトに一票
0113nobodyさん2009/09/19(土) 03:13:45ID:ZjH1gzNN
今のプロジェクトはASP.NETで作ってるんだが、どうしても必要なのでJavaScriptも死ぬほど書いてる。
自分で実装してて思うんだが、こんなの俺以外に絶対に保守出来ない。
つーか俺自身でも3か月後には多分保守出来ないｗ

難しいシステムを無理やりWebで作るのはほんとアホとしか思えないぜ。
0114nobodyさん2009/09/19(土) 04:39:22ID:???
うちは基本的にクライアントスクリプトの自前書きは禁止だなぁ@2.0環境
5行で書ける処理でもサーバー側でできるなら、そっちでやってもらってる。

>難しいシステムを無理やりWebで作るのはほんとアホとしか思えないぜ。
特に帳票とか帳票とか帳票とかな。まずデザインで死ねる。

更に、あたかも関数だらけのExcelのような動作を求められたりして死ねる。
入力項目50個超で1つ入力すると各項目を色々再計算／再描画とか言ってくるけど、
50個AutoPostback = trueな状態にするとブーブー言ってくるのは確定的に明らか。
こうなるとJavaScriptの出番になってしまい>>113みたいになって死ねる。
で、仕様変更があった時にJavaScript側で更に色々判定する必要がでてきてまた死ねる。

この経験からうちではクライアントスクリプト禁止令と、
「出来る出来ないで言えば出来ますが…は、ハッキリNoと言う」という
超基本的なことを徹底するようになった(´;ω;`)
0115nobodyさん2009/09/19(土) 15:13:10ID:???
教えて下さい。
コードビハインドで作られてるんですけど、3つのaspxが指すコードが全て同じものを指してる
んですが、これっていいんですか？まあ動けばOKという格言もありますが。

Form1.aspxとForm2.aspxとForm3.aspxが全部FormCom.aspx.csを指してます。
ちなみにFormX.aspxは3つとも微妙に違っていて、載ってるコントロールなんかも違います。
その辺はFindcontrolしてnullかどうかをちゃんとチェックしてるようなんですが。

でもまあ、通常は基底クラスに全部詰め込んで、あとは各画面に対応するクラスを継承するのが
正しい方法だと思うんですが。
0116nobodyさん2009/09/19(土) 17:07:25ID:???
>>115
>3つのaspxが指すコードが全て同じものを指してる
この発想はなかったわ。どう考えてもNGだろ。
0117nobodyさん2009/09/19(土) 19:01:05ID:???
メリットが思いつかないな
0118nobodyさん2009/09/19(土) 19:39:44ID:???
メリット
単純にコード記述量を減らせる。つまり試験工数も減るし、バグも減る。いい事尽くし。

3つのパターンで画面入力させるんだけど、画面上の項目が微妙に違う。(画面上の100項目の
うち10項目ほど）無論、3パターンを1画面でまかなって、区分によって項目のVisibleを制御
するのでもいいんだけど、いっそ3画面分のaspxを用意して、裏のcsは共通にしてしまおう、
と。デザイン指定が超絶シビアなので、Visibleで出したり隠したりとかしたくなかった。

基底クラスを継承、の場合でも、例えばボタンをクリックした場合のイベントはやっぱ3画面
それぞれ必要だよね。csが1つならとことんコード量を減らせる訳で。


まあ、「コード量が少ない」と「メンテしやすい」は等価じゃないけど。
0119nobodyさん2009/09/19(土) 19:40:53ID:???
>>116
すいません、NGの理由ってなんでしょうか？
0120nobodyさん2009/09/19(土) 20:00:26ID:???
自己ﾌｫﾛｳ
開いてる画面によってはコントロールがあったり無かったりするので、不用意に

TextBox1.Text = "ほげ〜";

とか書けなくなる。全画面共通で必ず存在しているコントロールじゃない限り、一々FindControl
でコントロールを探さなきゃならない。

デメリットってこれぐらいだと思うンすけど。
0121nobodyさん2009/09/19(土) 21:09:11ID:???
余りに阿呆らし過ぎて説明する気もおきん。
コボラ相手にしてる気分だ。
いいと思うならやればいいんじゃないンすか？
0122nobodyさん2009/09/19(土) 21:16:18ID:???
>>121
ページが最終的にコンパイルされる仕組みを理解していれば、特に何の問題も無いわけだが？
理解出来ないなら黙ってた方が無知を晒さずに済むと思われ。
0123nobodyさん2009/09/19(土) 21:22:24ID:???
ここのページに個別にJavaScriptを設定したくてもできなかったりとか
コントロール名を変更しても反映されなかったりとか
不必要なイベントハンドラメソッドが増えるとか
インテリセンスが意味をなさなくなってバグの温床になるとか
0124nobodyさん2009/09/19(土) 21:32:36ID:???
それは、そういうデメリットもあるから、メリット・デメリットを天秤にかけて考えてね。
ってだけの話で、やってはいけない。という理由にはならない。
でもまあ、個人的には動けば正義だと思ってる

ちなみに「不必要なイベントハンドラメソッドが増えるとか」これだけ意味不明。

0125nobodyさん2009/09/19(土) 21:45:24ID:???
>ちなみに「不必要なイベントハンドラメソッドが増えるとか」これだけ意味不明。
ボタンの数だけイベントハンドラメソッドが増えるでしょうが。
各ページに5個のボタンがあって、それぞれ別動作してたら15個のメソッドが存在することになる。

>でもまあ、個人的には動けば正義だと思ってる
保守性が下がるからやってはいけない
他人が見てもわけわからないことになるからやってはいけない
重複させるとインスタンス時に余計なサーバ資源を消費するからやってはいけない。
インテリセンスの動作が無駄になりバグの温床になるからやってはいけない。
エラー発生時にハイライトされた行が、どのページのエラーなのか一別しか分かりにくいからやってはいけない。
ページ初期化時に表示ページとは関係無い初期化にリソースが消費されるのでやってはいけない。

>それは、そういうデメリットもあるから、メリット・デメリットを天秤にかけて考えてね。
>ってだけの話で、やってはいけない。という理由にはならない。
デメリットのほうが圧倒的に大きいから「やってはいけない」ということでしょ。
単に自分がやってることを否定されたくないから、難癖つけて認めさせたいようにしか見えない。
0126nobodyさん2009/09/19(土) 21:46:50ID:???
各ページに5個のボタンがあって、それぞれ別動作してたら15個のメソッドが存在することになる。
↓
3枚の各ページに5個のボタンがあって、それぞれ別動作してたら15個のメソッドが存在することになる。
0127nobodyさん2009/09/19(土) 21:55:05ID:???
>126
普通、そういうケースではさすがにこんなヒネたコードは書かんだろ常考。
各画面にボタンが5個あって、ページに関係なく処理が同じ（前画面に戻るとか）
↓
15個のメソッドが必要なところを5個で済む

ていう事を言いたいんｼﾞｬﾏｲｶ？
01281212009/09/19(土) 22:11:27ID:???
>>122
アホかw本来別にすべきものをまとめて、
何がコンパイル時には一緒になるからだ。
App_Code以下が単一dllになるからって、
1クラスに全部まとめて書くか？書かないだろ？
なぜだ？責務が異なるものは、分けるのが当たり前だからだろ？

ある画面専用の処理が追加になったらどうするんだ？
他の画面からしたら、全く関係のない処理があるクラスを実装してることになるぞ。
リファクタリングを一回でもやったことがあれば、
それがどんなにアホなことか分かるよな。

月日が経って、そのクラスを実装するaspxが増えたらどうなる？
その度にif文やFindControl判定が増えていくのか？
なんとも素晴らしい設計だな。

仕様変更時には影響範囲が特定できず、
ある画面だけの修正なのに、処理が重なっているために
全画面の動作検証を行わねばならなくなったりしないか？

つか、高凝集密結合が良くないなんて、学生でも分かるだろ？

で、業務上、そういうことにはならないように気を使ってますとでも言うのなら、
先に述べたように、お好きにどうぞってこった。
0129nobodyさん2009/09/19(土) 22:26:02ID:???
多分元の質問者は「技術的に問題ありますか？」って事を聞きたいだけだと思われ。
そういう意味では「注意深く作るなら、別に問題はない」が回答。

ただし「将来的なメンテとか拡張とか修正とか考えると、3画面分まとめて1ソースに
すると身動き取れなくなったりしない？止めとけば？」ってのが周りのアドバイス。
0130nobodyさん2009/09/19(土) 23:06:31ID:???
>>127
>ちなみにFormX.aspxは3つとも微妙に違っていて、載ってるコントロールなんかも違います。
って言ってるぞ。
0131nobodyさん2009/09/20(日) 06:26:46ID:???
知識のない奴が一人前に提案して
不備を指摘されると逆ギレ
誤りを認めたくないから強弁するってガキの流行なんか？
0132nobodyさん2009/09/20(日) 14:01:24ID:???
>>130
で？
0133nobodyさん2009/09/20(日) 14:03:21ID:???
俺が認めない方法は許さない。
って馬鹿の粘着ｷﾓｲ

>129 で出てる回答が全て。あとは自分で判断しろってことで終了。
0134nobodyさん2009/09/20(日) 15:36:43ID:???
>>133
技術的に問題があるかどうかなんて聞いてないよ
本人は技術的には問題ないことを理解した上で、メリットデメリットの話をしてるんだから。

技術的に問題無いことを理解している発言は>>122でしてる。（技術的に）何の問題もないと。
メリットとデメリットの話をしようとしているのは>>120を見れば分かる。デメリットうんたらかんたらと。
0135nobodyさん2009/09/20(日) 16:07:08ID:???
エスパー登場
0136nobodyさん2009/09/20(日) 16:48:16ID:???
なんか、ある事例を今の我が事のように感情移入してしまう人が居ますが、
その3画面での共用する方法はある意味、仕組みを熟知して使い倒してますなｗ
ネイティブアプリでの共有ライブラリ、DLLの様ように。
禁止事項ではないから、開発&保守が効率的であればそれも選択肢としてアリだと思う。
0137nobodyさん2009/09/20(日) 17:05:18ID:???
熟知しての実装なのか、無知ゆえの実装なのかはともかく（後者っぽいけど）、ケースに
よってはそういう手もあるのかと知ってちょっと感心した。

ビハインドコード共有！そういうのもあるのか

みたいなｗ
機能的に全く完全に差異がないけど、デザイン的にどうしようもない（ある仕入先と別の
仕入先で全く異なるデザインの画面）ケースなんかでは有効かも。
0138nobodyさん2009/09/20(日) 17:09:01ID:???
>なんか、ある事例を今の我が事のように感情移入してしまう人が居ますが、
４：主観で決め付ける

>ネイティブアプリでの共有ライブラリ、DLLの様ように。
６：一見関係ありそうで関係ない話を始める

>禁止事項ではないから、開発&保守が効率的であればそれも選択肢としてアリだと思う。
１：事実に対して仮定を持ち出す
10：ありえない解決策を図る
12：決着した話を経緯を無視して蒸し返す

というか自演乙
0139nobodyさん2009/09/20(日) 17:54:42ID:???
というか、aspxのページを新規生成すると、
ロジックを記述するパーシャルクラス(ページなんちゃら.aspx.cs)と、
コントロールなどのメンバ変数を宣言する.aspxが自動生成するパーシャルクラスの
二つが作られるわけでしょ？

後者はVSがページ毎に自動生成するからaspxと1対1になってる
コードビハインドは、そのメンバ変数を参照してる（からインテリセンスで補完してくれる）わけで
いくらpageのインスタンスを所有していて、そこからFindControlで操作したいコントロールを見つけられるとしても
メンバ変数として宣言されてるコントロールを一切使用しないなんて、
asp.net以前にオブジェクト指向の設計として間違ってるような気がするのは俺だけ？

クラスで例えれば、
メソッド内では決して参照しないまったく関係無いコントロールのインスタンスをメンバ変数として保持し、
メソッド内で操作したいコントロールのインスタンスは、すべてメソッドの引数として得て操作してるような感じ。
じゃあ、メンバ変数として所持してるインスタンスってなに？
その都度無駄にコントロールのインスタンスを生成するの？ってな感じになると思うんだ。

技術的に問題ないとか、問題なければやってもいいだろとか別次元の話だと思うんだけど。
動けば害はないし、禁止されてないからということで、1行ごとにThread.Sleepをしかけまくるみたいな。
0140nobodyさん2009/09/20(日) 17:58:03ID:???
君さ、もう「宗教上の理由で俺は断固として認めない」とでも言えば？('A`
01411392009/09/20(日) 18:05:49ID:???
なんだかわからんが、初の書き込みなんだが
というかで始めたのがまずかったか
■ このスレッドは過去ログ倉庫に格納されています