 |
|
|
|
|
4.アプリを作る（本気編） |
「本気」と書いて「マジ」とは読まず、「エンタープライズ」と読みます。
基本技で概念を学ぶことは必要ですが、どうしてもそれをそのままは使えないところがあります。
そこで、もう少し、仕事で使えるように、各機能の理解を掘り下げて行きたいと思います。
ところで、この辺で環境を更新しておきます。
http://www.exconn.net/Blogs/team01/archive/2005/04/28/351.aspx
を参考に、まずは既存環境をアンインストールしてから、Visual Studio 2005 Beta2 日本語版をインストールします。
ログによると、20分弱かかっているので、一気にやってくれるこういうツールは、役に立ちますね。
インストールはあっさりできました。VSSや最近使ったファイル等は残っていました。
ただし、XMはやはりだめでした。
※Beta1からBeta2への変更点は下記参照
http://msdn.microsoft.com/asp.net/whidbey/beta2update.aspx
CompileWith→CodeFile等
4-1.マスターページを使うべきか
いざ作り出そうとするときに、最初に決定を迫られるのが、マスターページを使うか否かです。
これについては、以下のようなトレードオフがあると思います。
＜利点・必要性＞
・レイアウト全体の修正のような場合に、各ページを変更する必要がない
・各ページの中身を書きながら複雑なレイアウトを壊してしまうことがない
＜欠点・不要＞
・ユーザコントロール等でも共通性確保は可能
・コンテンツページはHTMLでなくなる
＜評価＞
コンテンツページには、contentの中身しか書けません。よく言われる、
デザイナとの作業の分離ということは、私はあまり幻想を持っていませんが、
それにしても・・・という気持ちはあります。
また、階層の違うページに対する、相対パス記述ができないことが難点だと思っていたのですが、
下記のページで
<% =Request.ApplicationPath %>
を記載する方法が紹介されており、それはなるほどという感じです。
こんなことを書き出したのは、マスターページの使用は難しいのでは、と思ったからなのですが、
結局、ユーザコントロールを使い出した時点で、
VS以外でのHTML編集はある程度あきらめざるを得ないということと、
サーバ側の記述で問題点は解消できるのではないかという見通しの下、
マスターページは使っていきたいと思います。
（参考情報）
ASP.NET 2.0 のマスター ページ
※ところで、beta2固有の問題かもしれませんが、マスターページの名前はデフォルトのMasterPageがよいかなと思います。
beta2で、ビハインドのクラス名に「_asp」が付かなくなりました。とすると、マスタページの名前とWebフォームの名前が重なると
ビルドできなくなります（重ならないように勝手にクラス名の先頭に「_」が付けられますが、それがそれで問題のようです。）。
4-2.GridViewへのデータバインド
チュートリアル等でサンプルとして紹介される場合、データバインドの方法としては、一見簡単なデータを直接参照する
方式が採用されることが多いと思います。
しかし、実際は、SQLは既に作成されていることがあったり、他と共有する必要があることから、各ページにSQLが埋め込まれる
方式は、あまり採用しないと思います。
それでも、ストアドプロシージャを使っている場合は、データベースのバインドでよいのですが、コードで生成している場合はどうするか。
これまでの流れで考えるとコードで動的に割り付けることになると思うのですが、今回はオブジェクトをバインドすることができます。
基本的にはこれがよいのではないでしょうか。
※オブジェクトの選択のところで出てくる「データコンポーネント」というのが、まだ調べ切れていません。
本当はそれがよいのでしょうけど、ウィザードに出てこないんですよね・・・。
※これでやると、GridViewのプロパティだけで並べ替えを有効にする、という機能が効かないかもしれません。
これも調査中ですが、これは強力な機能なので、効かなくなってしまうのは惜しいです・・・。
既存のDataGridの移行に関してですが、aspx側はBoundColumnをBoundFieldに置換してあげればよいです。
それだけで済む場合もあるかもしれませんが、そうは言ってもコードで処理したい場合もあるとは思います。
それについて、DataGridの場合に、ItemDataBoundイベントで、ヘッダ等の場合を無視してデータについてだけ処理するために
Select Case e.Item.ItemType
Case ListItemType.EditItem, ListItemType.Item, ListItemType.AlternatingItem
みたいな事を書くことがあったと思いますが、若干構造が変わっていて
Select Case e.Row.RowType
Case DataControlRowType.DataRow, DataControlRowType.EmptyDataRow
になります。
もうちょっと追記・・・
ItemCommandイベントもRowCommandイベントになりますが、 e.Itemで取得できていたイベント発生元の行は、
違う方法で取得することになります。
Dim index As Integer = Convert.ToInt32(e.CommandArgument)
Dim row As GridViewRow = Me.GridView_PT.Rows(index)
こんな感じです。
4-3.DetailsView・FormView
ちょっとブログに書きましたが、
正直、どちらも微妙です。このままで許されるのは自分たちで使うようなやっつけアプリの場合だけのような気がします。
もう少し保留にしておきますが、一点だけ覚書。
元になるGridViewがキーを二つ持っているような場合だと、選択したデータをDetailsView等に表示させるのは困難です。
強いて言えば、キーのうち一つはセッションに持っているような場合だと、もう一つだけを取得すればよいので、不可能ではないですが、
その場合は、GridViewのDataKeyNamesプロパティで、取得するほうを先頭に書いておきます。
（http://beta.asp.net/QUICKSTARTV20/aspnet/doc/data/databases.aspx
の「Master-Details and the DetailsView Control」参照）
この辺はちょっとどうかなというところですね。
（続く・・・）
|
|
|
|
『WEB MAGIC』さんにお世話になりました。