2006年7月 Archive

仕事でURLの置き換えをする必要が出てきたので、IHttpModuleを使用することにする。
受信フィルタとも呼ばれる仕組みらしいですが、メリットとしてはaspxの画面が開かれる前に呼ばれる点でしょう。
呼ばれたページが開かれた際にリダイレクトするより、ページが開かれる前にURLを書き換えてしまうほうが、よりスマートと言えるのではないでしょうか。

URLの置き換えを知るには、以下のページが参考になると思います。
ASP.NET での URL 書き換え
MSDN:特集2.NET実践プログラミング PartVII ASP.NET ISAPIとASP.NETのもとでHTTPフィルタを使ってWeb要求を横取り，監視，変更する
URL Mapping for ASP.NET 1.1
ASP.NET 2.0: Rewriting URL Paths just got a whole lot easier
ASP.NET 2.0: URL Mapping with RegEx Support

また、URLの書き換えだけでなく、HTTPモジュールについても知っておく必要があります。
HTTP モジュールの概要
方法 : カスタム HTTP モジュールを作成する
ASP.NET アプリケーションのライフ サイクルの概要
@IT:［ASP.NET］アプリケーション共通のロギングを行うには？（HTTPモジュール編）

HTTPモジュールを使うとして、問題になりそうなのが単体試験をどうやってやるかってことなんですが、
Visual C# .NET を使用して ASP.NET HTTP モジュールを作成する方法
テスト方法が載っているけど、こういう方法じゃ単体テストとは言えないですね。
NUnitAspを使う方法で考えてみようと思います。

システム内部で唯一のインスタンスがほしいときは、Singletonパターンが有効的な手段になります。
具体的な利用例としては、共通変数の管理や滅多に変更されないコードと名称の組み合わせを持っておく等が考えられると思います。

私はJavaでデザインパターンを覚えたこともあって、インスタンス取得のために GetInstance のようなメソッドを用意したいたのですが、もっと画期的な方法がありましたので紹介したいと思います。
C# でのシングルトンの実装
画期的と言っても、実装方法はほとんど変わらず、プロパティを利用しただけなのですが、コードはとてもすっきり見やすくなっています。
応用例としてマルチスレッド対応のシングルトンや静的な初期化も説明が載っています。

先日から悩んでいるJavaScript問題ですが、Literalを配置しておき、どこかしらのイベントでjavaScriptを埋め込んでやることで一応の分離は可能でした。
あとは、埋め込んでやるJavaScriptをある程度生成できるような抽象Builderクラスを作り、サブクラス化するようにすれば、それなりに再利用もできそう。
また、デバッグ実行時のみJavaScriptを返すようなサブクラスを作成してあげれば、テスト時も少しは楽になるかもしれません。
Literalの配置はマスターページで行えば、処理の手順を共通化することもできそうだ。
JavaScriptが必要ない画面であれば、そのまま放置しておいても特に問題ないし。（気分的には気持ち悪いけど）

と、このあたりまでは普通に思いつくんですが、どうにもすっきりしないんですよね。
JavaScriptを力ずくでどうにか手なずけようとしている訳だから、当たり前といえば当たり前なんですが．．．
ぐぐってみたものの、同じようなことを企んでいる人はほとんどいない状況でした。イエイ！
やっぱり、ずるい方法だよなあと思いつつ、もうどうでもよくなってきたので、このまま実装することに決定（おい）。

テーブル情報の取得と同じように、SYS***関連のテーブルを結合することで取得できます。
得たい情報によって結合するSYS***が変わりますが、大体こんな感じになるんじゃないかなと思います。
少々長いですが、フィールドの方向やIDENTITYかどうかも取得できるようになっています。
必要に応じて追加・削除してくださいまし。

SELECT 
  CAST(A.NAME AS VARCHAR(40)) AS FIELD_NAME, 
  CAST(C.NAME AS VARCHAR(20)) AS FIELD_TYPE, 
  CASE WHEN A.STATUS & 8 = 8 THEN 1 ELSE 0 END AS DIRECTION_INPUT,
  CASE WHEN A.STATUS & 64 = 64 THEN 1 ELSE 0 END AS DIRECTION_OUTPUT,
  CASE WHEN A.STATUS & 128 = 128 THEN 1 ELSE 0 END AS IS_IDENTITY,
  A.LENGTH AS FIELD_SIZE, 
  CASE WHEN E.COLID IS NULL THEN '0' ELSE '1' END AS PK_FLAG, 
  A.NUMBER AS PROCEDURE_NO 
FROM 
  SYSCOLUMNS AS A 
  INNER JOIN SYSOBJECTS AS B ON B.ID = A.ID 
  INNER JOIN SYSTYPES AS C ON C.XUSERTYPE = A.XTYPE 
  LEFT JOIN SYSINDEXES AS D ON D.ID = A.ID 
      AND D.STATUS & 2048 <> 0 
  LEFT JOIN SYSINDEXKEYS AS E ON E.ID = D.ID 
      AND E.INDID = D.INDID 
      AND E.COLID = A.COLID 
WHERE 
  B.NAME = '対象テーブル名' 
ORDER BY 
  A.NUMBER, 
  A.COLID

このSQLでは、テーブル以外にもストアドの情報まで取れるようになっています。
PROCEDURE_NOが1以上のときは、ストアドで使用される項目となります。

ASP.NETの画面を見ていると、当然のごとくJavaScriptが出てくる。
よくよく考えてみると、JavaScriptはエンジニアに嫌われる代表的な技術だと思う。
ブラウザ依存するし、デバッグは面倒くさい。
作り方によってはセキュリティに影響を与えることもある。
しかも、ブラウザの設定でオフに出来ちゃう。
でも、応答速度を求められると、これを使わざるを得ないのが現状なんですよね。

あと、とっても気になる点として、コードとビューの分離「コードビハインド」に関わる問題があります。
ASP.NETでは、JavaScriptで処理していたコードをイベント記述することで、コードとビューを分割できることを売りの一つとしています。
要は、「画面は画面、ロジックはロジック」とハッキリさせた方が分かりやすいし、メンテナンスしやすいでしょ？ってことなんだと理解してます。
従って、いくら入力チェックとはいえ、HTML（ASPやJSPも含む）上にロジックを書くってのは、ちょっと違うんじゃないかなあと思うわけです。

しかしながら、現実的に目の前に広がる世界にはJavaScriptが溢れているわけで、急に無くすと政治的な問題になりかねないので、思案のしどころです。
とりあえずの策として、WEBコントロールのAttributeにJavaScriptを突っ込む方法でいこうかと考えていますが、普通はどうやるんでしょうね？？？

謎は深まるばかり。

データベース内にどんなテーブルが存在するかは、以下のSQLを実行することで得られる。

SELECT NAME, TYPE 

FROM sysobjects 

ORDER BY TYPE, NAME

所有者もほしいときは、sysusersを結合させて、UID同士を結合させる。

SELECT B.NAME AS OWNER, A.NAME, A.TYPE 

FROM sysobjects A JOIN sysusers B ON A.UID = B.UID 

ORDER BY A.TYPE, A.NAME

システムテーブルが邪魔な場合は、

SELECT B.NAME AS OWNER, A.NAME, A.TYPE 

FROM sysobjects A JOIN sysusers B ON A.UID = B.UID 

WHERE A.TYPE IN('U', 'IF', 'TF', 'V', 'P') AND A.STATUS >= 0 

ORDER BY A.TYPE, A.NAME

使う場合は、自己責任でお願いします。

System.Data.Common 名前空間
ADO.NET でのプロバイダに依存しないコードの作成

これすごいです。
7/4の記事でポリモーフィズムがどうたらとか書いていたんですが、もうどうでもいいです（泣）
VisualStudio.NET 2003までは、各プロバイダ用にサブクラス化していた（さらに言うと、依存DLLの関係でプロジェクトも分けていた）んですが、もうそんな必要は無いようです。

で、早速使ってみました。
たとえば、SqlParameterなんかの場合はDbParameterなんて感じになります。
基本的にDb****という命名になるようですね。
Newする際には、ファクトリクラスを使ってCreateするだけのお手軽さでした。
デバッグ実行でブレークしたついでに、オブジェクトの状態を見てみると、ちゃんとプロバイダごとのオブジェクトが生成されてます！
速度も特に遅いと感じたこともなかったので、今後はこれがスタンダードになるのかな。

テスト用にVisualStudioの出力ウインドウにメッセージを表示させたいとき、System.Diagnostics.Debug、System.Diagnostics.TraceのWriteメソッドを使用します。

両者の違いは、それぞれDEBUGディレクティブ、TRACEディレクティブが宣言されているかどうかです。
この宣言はVisualStudio2005の場合、プロジェクトのプロパティでチェックするだけで宣言したことになります。

[HOWTO] Visual C# .NET でのトレースとデバッグの方法

O/Rマッピングを調査中です。
というか、激しく悩んでいます。

O/Rマッピングを簡単に説明すると、オブジェクトとリレーショナルデータベースを自動的にマッピングする仕組みです（簡単すぎ：汗）。
Hibernateなんかが有名なんですが、SQL文、データベース名とオブジェクト名のマッピング、テーブルのカラムとクラスのフィールドのマッピング等をXMLに定義しておくことで、自動的に変換してくれる仕組みです。

これを導入することで、オブジェクト指向とリレーショナルデータベースの思想の違い（インピーダンスミスマッチ）を解決できるし、ビジネスロジックにSQLが紛れ込むこともなくなります。
また、SQLがXMLに書かれるため、メンテナンスがし易いといったメリットもあるのです。

当然のことながら、C#でも実装できますし、オープンソースでもいくつかあります。
ところが、.NETではDataSetというのがあって、これを使うことでデータグリッド等の表示が簡単に行えるので、わざわざエンティティクラスを定義する必要があるのか微妙なところです。
というか、DataSetをエンティティクラスの代わりに使うこともできちゃいますし。（現実世界の構造とは狂うかもしれないが）
あと、DataTableを変更したときに、変更内容に応じて自動的にInsert、Update、Deleteを行ってくれる機能まであったりする。
しかも、Abstractクラスでメソッド宣言するときに、パラメータなんかとインタフェースで定義しておいて、実装はサブクラスで行うようにすれば、ADO.NETだけでなく、ODP.NETやpgsqlでも、ポリモーフィズムが実現できる。

また、SQLをXMLに書くというのも、私は大歓迎ですが、O/Rマッピングを知らないエンジニアがすんなり受け入れてくれるとも思えないんですよねえ。
とりあえず、
・SQLをXMLに書かないが、データベース層に該当するクラス内に閉じ込める
・DataSetを返す
・機能（SELECT、INSERT、UPDATE、DELETE）と実装（SQLの実行、トランザクション処理、コネクション管理）を分ける
といったあたりを念頭にコーディングしてみることとする。

トラックバックの練習です。

トラックバック練習板もあるようです。
トラックバックとは？
トラックバックのやり方
トラックバックの練習をしよう！
トラックバック初心者のみなさん！　トラックバックの練習どうぞ！
トラックバック練習用
トラックバック練習
tokuriki.com

タイトルのとおり、情報セキュリティアドミニストレータを受験します！

この試験は今回で２度目になります。
１回目はテクニカルエンジニア・ネットワークの難しさからの現実逃避だった訳です。
昨年の秋に、そのテクニカルエンジニア・ネットワークに合格したため、リターンマッチをしようと思った訳です。
前の職場では、情報処理試験対策（基本情報ですが）の講師をやっていたこともあって、資格取得には前向きだったりします。
資格が全てではありませんが、力を証明する一つの手段ではあります。

話は戻りますが、とりあえず問題集を２冊購入しました。
トップページに画像が貼ってありますが、個人的にはITECの問題集がお勧めです。
なぜか？それは難しいから！（汗）
正直なところ、本試験より難しいです。
しかし、逆に言えば、この問題集を理解できるレベルまで到達すれば、合格が現実的なものになるはずです。

さて、具体的な合格へのロードマップですが．．．
まず午前問題は予想問題集に載っているあたりを一回流す程度です。
午前問題はソフトウエア開発技術者に合格できるレベルであれば、高度区分でも十分通用します。
私の場合、ソフトウエア開発技術者（当時は一種）の午前対策をかなり煮詰めたこともあって、ここ数年は午前対策をしないでも７３０点以上は軽く超えていました。
後は午後対策で出てきた用語をしっかり抑えておくだけで十分だったりします。
というか、午前で手こずっているようでは合格は無理でしょう。

午後対策は、まず過去問題をこなすこと！
当然のことながら、同じ問題は出ない訳ですが問題の傾向を体で覚えます。
ITECの問題集は解説も深いので、理解できるまで何度でも繰り返す必要があります。
ここまでを試験一ヶ月前まで終わらせる。
残りはひたすら予想問題集を解きまくる。
これは知識や回答の仕方の幅を広げるのに役に立つと考えています。

１２月に合格を報告できればいいな。