フレームワークのデータベースアクセス部分だが、J2EEパターンで出てくる「DAOパターン」を採用することとした。

データベース操作については、特にコーディングをしないでも、テーブル構造合わせて自動的に処理させようと企んでいたのですが、どうやら破綻してしまったようだ。
SQLが固定でパラメータクエリで実現可能な一般的な操作（PKに対する検索、全件取得、追加、更新、削除）は普通に実装できたのだが、問題は動的にSQLが生成されるようなときに自動化はちと難しいのです。

解決策として最初に考えたのは、条件部分をDecoratorクラスで実装する案。
実はこれは上手くいったのですが、どうも美しくない。
複数クラス間にSQLが分散されているため、メンテナンスが容易にできないだろうと。

そこで、自動生成そのものを見直すことにしました。
今まではオブジェクト生成時に自動生成していたため、生成されたSQLに手を入れることはできず、実行直前に文字列の置き換え処理で対応していた。（置き換え処理はIn句対応で実装済みだったが、本来の意図とは違います）
これを、実行する直前まで遅らせることで、条件にしたがってSQLを自由に構成できるようになった。
同じSQLを実行する際に毎回SQLを生成するようになってしまったが、気が付かなかったことにしようっと。

ASP.NET2.0からGridViewが追加されているので、DataGridからの置き換えをしているのですが．．．

現行プログラムをGridViewに置き換えると、BRタグなどのタグがそのまま表示されたりします。
というか、問題があるとするならば現行プログラムの方で、タグがそのまま表示されるってことはクロスサイトスクリプティングの脆弱性があるってことなので、GridViewが正しいのは間違いないんですが。

しかしながら、当面の問題として現行プログラムを移行しなければいけない訳で、ほうっておく訳にもいかないので調査してみました。
結果から言えば、BoundFieldを使用せずに、TemplateFieldを使用してItemTemplateの中で <%# DataBinder.Eval(Container.DataItem, "フィールド名") %> をするだけでタグが有効になりましたが。

クロスサイトスクリプティングみたいな基本的な脆弱性が残っているプログラムって、意外と多いなあと思う今日この頃。

Javaエンジニアから.NETエンジニアに転向して感じたこと。
それは、アプリケーションフレームワークがほしいなあということでした。

Spring.NETとかあるようですが、なんか説明を読んでいて面倒くさくなってしまった。
個人的な感覚ですが、どうもSpringは発想が私とは合わない（Springが悪いという意味ではありません）気がするし。
それなら作るしか！と最近考えています。

大体、こんな感じになります。
・オープンソースで晒します
・無料ライセンスでＧＯ！
・技術的な敷居が低いこと
・シンプルだけど拡張性が豊かなこと
・コードの多くを自動生成できること
・制限事項が少ないこと（最重要課題）

最重要課題の「制限事項が少ないこと」は非常に難しいところです。
作りにこだわったり、機能を増やしていくと、想定していないような制限事項が出てくることがあるからです。
まずはとりあえずのフレームワークを作成し、それを利用した別プロジェクトをどんどん作っていこうかと思っています。
仕事で実際に使えるような人事システムとかそういうものを作っていくことで、フレームワーク作成で見えてこなかった部分が見えてくると思うからです。
最終的には企業内で必要となるシステム全部（は言い過ぎか）を作っていけたらとか考えています。

既に開発はスタートしているので、製作状況をどんどん伝えていこうかと思っています。

ASP.NETのデバッグ実行時に、ASP.NET開発サーバが起動するのですが、これがランダムなポートなのでいろいろと面倒な場合があります。
（例えば、WEBプロジェクトを複数のソリューションに追加すると、ソリューションごとにポートが違ったり）
ただ、ランダムに設定されるのは初回だけで、以降は同じポートを使い続けています。
ということは、ソリューションファイルかな？ということで覗いてみました。

VWDPort = "ランダムに設定されたポート番号"
と書いてあるあたりが怪しいので、早速変更してみるとビンゴ！

※ソリューションファイルをテキストエディタで変更する方法なので、自己責任で行うようにしてください。
　何か不具合がありましても責任を取りかねます。
　念のため、バックアップしておく等の措置を行った方が良いと思います。