.NET Developer Empire

今日はありがとうございました！

tatsumihr(honekichi19@hotmail.com) — Sun, 19 Oct 2008 01:23:00 GMT

tatsumihrです。
今日の勉強会はありがとうございました。
スピーカーにもかかわらず勉強会参加登録をしていなかったという大失態を犯しましたが、
みなさんが暖かく受け入れてくださったのでとても嬉しかったです。

今後も都合が許せば参加しようと思いますので、
よろしくお願いいたします。

今日、発表で使ったデモはSourceForge.jpに公開しているチュートリアルのサンプルAPです。
チュートリアルには基本的なTERASOLUNAの使い方をかなり詳細に書いていますので、
是非、ご覧ください。

さらにTERASOLUNAフレームワーク自体のソースコードも
Apache License, Version 2.0 で公開しています。
業務システム開発や勉強などで活用してください。
そして、もし怪しいところがあったらこっそりご連絡くださいｗ
もう一度言います。
『こっそり』ご連絡ください！

明日の野球もがんばります。。。
今日は本当にありがとうございました。

-----
◆TERASOLUNAフレームワーク
http://sourceforge.jp/projects/terasoluna/

◆@IT
TERASOLUNA for .NETフレームワーク概説
「.NET開発でもオープンソース・フレームワークを使おう」
http://www.atmarkit.co.jp/fdotnet/terasoluna/terasoluna01/terasoluna01_01.html
-----

TERASOLUNA Server/Clinet Framework for .NET

tatsumihr(honekichi19@hotmail.com) — Tue, 15 Jul 2008 08:06:00 GMT

●NTTデータが社内で利用中の.NET向けフレームワークをオープンソースとして無償公開

http://itpro.nikkeibp.co.jp/article/NEWS/20080714/310757/

やっとリリースしました。

◆Client

Windowsアプリケーションのオープンソースフレームワークはあまりないので、なかなか面白いのではないかと考えています。

特に、サーバ側としてTERASOLUNA Server Framework for Java(Rich版)との連携を考えて設計しているため、サーバJava(Springベース)、クライアント.NETという組み合わせでの開発もできます。大規模システムでサーバ側をJavaアーキテクチャで統一したいが、クライアント側はどうしてもデバイス操作が必要なため、.NETで開発したいという場合に、よくこの組み合わせで開発されます。

Windowsフォームが中心でWPFには対応していませんが、拡張すれば使えると思います。

◆Server

ASP.NETの機能ってかなり豊富で、実はJavaほどフレームワークって必要ないのではないか？と考えています。規約さえあれば、そこそこのものは作れてしまいそう。

でも、ASP.NETのプレゼンテーションレイヤ周りの機能って結構気が利かないところもあって、分散開発には向かないところも多々あります。例えば、　Response.Redirect("UI/Sample.aspx");　とか、リダイレクト先の指定でURLを直接書きますが、これだとリダイレクト先の変更にリビルドが必要になってしまうので、イケていません。それを　WebUtils.Transit(uiId);　という形で、ページ設定ファイルに切り出した画面IDでリダイレクトできるようにしています。ページ設定ファイルには画面のトークンチェックの設定も一緒にできるので、少ない設定ファイルで標準のASP.NETではない機能を簡単に追加できます。

あとは、スマートクライアント開発でマルチパート形式のデータの受け口があったりもします。 XML通信でいいなら、.NET標準のWebサービスやWCFを使うのがいいのかな？とも思いますが。

セッション管理のお話

tatsumihr(honekichi19@hotmail.com) — Thu, 27 Sep 2007 09:23:00 GMT

セッションって便利で、結構何でも入れてしまいがちです。「セッションに何でも入れてしまうなんてとんでもない！！」と思う人は、しっかり考えてセッション使ってくれるので問題ないですが、中にはそういう考えを全く持っていない人もいる訳です。

また、セッションに値を格納したら、しかるべきタイミングで不要なものは削除しなければなりません。ログアウト時などに一括削除するのであれば Session.Clear() で良いのですが、おそらくそうでない場合の方が多いでしょう。通常は設計時にセッションに格納する値を決めておいて、削除するタイミングも決めておくと思います。ほとんどの場合はこれで問題ないはずです。しかし、セッションに何でも値を詰め込んでしまう人が設計書を無視して実装してしまった場合、どこでどのタイミングでセッションを削除すれば良いのか分からなくなってしまいます。不要な項目がセッションの中をウヨウヨしてしまいます！

さて困った。。。

良い意味で開発者を信頼しないで、セッションを管理できるような良い仕組みってないですかねぇ。。。

CloseとDisposeの違いって？その２　～実装を覗いてみよう～

tatsumihr(honekichi19@hotmail.com) — Sat, 11 Aug 2007 10:03:00 GMT

CloseとDisposeの違いって？でCloseは再オープン可能、Disposeは再オープン不可能という話になりました。

じゃあ、.NET Frameworkの実装ではどうなってるの？という疑問に当然たどり着くわけです。「プログラムは仕様通りに動くのではなく、実装通りに動く！」という名言もあります。調べてみたのはStreamとConnection。本当かどうかは分からないので、あまり信じすぎないでね。

ストリーム

public void Dispose() 
{ 
　　// Close()を呼び出す 
}

public virtual void Close() 
{ 
　　// 実際にストリームを閉じる処理をする
}

ストリームでは、DisposeメソッドはCloseメソッドを内部で呼び出しているようです。この場合、一度Closeしてしまったら再Openはできません。

では、Connectionはどうでしょうか？要約すると、多分こんな感じ。嘘だったらごめんなさい。

コネクション

public void Dispose() 
{ 
　　// コネクションを閉じる
}

public virtual void Close() 
{ 
　　// 現在持っているDbConnectionをクラス内部のコネクションプールにキャッシュしている感じ？ 
}

DisposeするとDbConnectionにGCがかかりそうな予感。Closeの場合は、クラスの内部的にキャッシュして持っているだけなイメージ。つまり再オープン可能。

こういう風に実装が違うのって、扱う対象の性質に合わせているのかな？FileStreamだと閉じた後にしっかりリリースしてくれないと、他のところから書き込みとか行った場合に不整合が生じてしまいそう。DbConnectionだと、コネクション作るのに時間かかるから、毎回完全にリリースしてしまうと効率が悪そう。個人的に大体こんな結論になりました。

CloseとDisposeの違いって？

tatsumihr(honekichi19@hotmail.com) — Tue, 07 Aug 2007 22:35:00 GMT

Close

一般に、Closeは、オブジェクトをクローズしたあとも再オープン、再利用できるときに使う。ファイルのように一般にクローズされるとみなされているオブジェクトに対してもCloseを使う。

Dispose

捨てたあと再利用できないオブジェクトで使う。たとえば、System.Drawing.Brushオブジェクトを削除するには、そのDisposeメソッドを呼び出す。捨てたあとのBrushオブジェクトは利用できず、オブジェクトを操作するメソッドを呼び出すと、例外が発生する。ほかのBrushが必要なら、新しいBrushオブジェクトを構築しなければならない。

これは「ガベージコレクション入門: Microsoft .NET Framework の自動メモリ管理 Part I」で書いてあった事です。

どなたかのblogでここへのリンク先が書いてあったのですが、普段無意識に使っているものでもあらためて比べてみると、「ああ、なるほど」と思わず納得してしまったことでした。

それにしても、「一般にクローズされるとみなされている」という定義はいったい何なのだろうか？？？

えムナウさんからの宿題

tatsumihr(honekichi19@hotmail.com) — Sun, 05 Aug 2007 20:08:00 GMT

先ほど書いたValidation Application Blockの記事で、えムナウさんから型付データセットのRewardPoints（System.Int32）に文字列を入れたら入力値検証前に落ちるのではないか？とのご指摘を受けました。

Validation Application Block を使おう！！　～構成ファイル編～

確かに、おっしゃる通りです。

そこで対応策。

RewardPoints の System.Int32 を System.String 型にしてしまい、カスタムValidatorを作って対応します。カスタムValidatorでは、Stringをintに変換し、変換したintに対して検証をかけるという感じです。実装例は以下の通りです。

using System;

using System.Collections.Generic;

using System.Text;

using Microsoft.Practices.EnterpriseLibrary.Validation.Validators;

using Microsoft.Practices.EnterpriseLibrary.Validation;

using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;

using Microsoft.Practices.EnterpriseLibrary.Validation.Configuration;

using System.Collections.Specialized;

namespace ValidationABSample.CustomValidator

{

[ConfigurationElementType(typeof(CustomValidatorData))]

public class IntRangeValidator : Validator

{

private int _lowerBound = 0;

private RangeBoundaryType _lowerBoundType = RangeBoundaryType.Ignore;

private int _upperBound = 0;

private RangeBoundaryType _upperBoundType = RangeBoundaryType.Ignore;

// コンストラクタ

public IntRangeValidator(NameValueCollection attributes)

: base(null, null)

{

_lowerBound = Int32.Parse(attributes.Get("lowerBound"));

_upperBound = Int32.Parse(attributes.Get("upperBound"));

if (attributes.Get("lowerBoundType").Equals("Exclusive"))

{

_lowerBoundType = RangeBoundaryType.Exclusive;

}

if (attributes.Get("lowerBoundType").Equals("Inclusive"))

{

_lowerBoundType = RangeBoundaryType.Inclusive;

}

if (attributes.Get("upperBoundType").Equals("Exclusive"))

{

_upperBoundType = RangeBoundaryType.Exclusive;

}

if (attributes.Get("upperBoundType").Equals("Inclusive"))

{

_upperBoundType = RangeBoundaryType.Inclusive;

}

// デフォルトメッセージ

protected override string DefaultMessageTemplate

{

get { return "数値範囲チェック。The value must fall within the range {0} ({1}) - {2} ({3})."; }

}

// 検証メソッド

protected override void DoValidate(object objectToValidate, object currentTarget, string key, ValidationResults validationResults)

{

if (objectToValidate != null)

{

try

{

int valueToValidate = int.Parse(objectToValidate.ToString());

RangeValidator<int> validator = new RangeValidator<int>(_lowerBound, _lowerBoundType, _upperBound, _upperBoundType);

ValidationResults results = validator.Validate(valueToValidate);

if (!results.IsValid)

{

string message = string.Format(DefaultMessageTemplate, _lowerBound, _lowerBoundType, _upperBound, _upperBoundType);

this.LogValidationResult(validationResults, message, currentTarget, key);

}

catch (FormatException)

{

string message = "数値を入力してください。";

this.LogValidationResult(validationResults, message, currentTarget, key);

}

このカスタムValidatorを使って検証することで、文字列でなかったら「数値を入力してください。」というメッセージを、数値で範囲チェック違反があったら、設定したデフォルトメッセージを表示するようにできます。

EnterpriseLibraryのValidatorを継承することで、こんなようにカスタムValidatorを自由に作る事もできます。

こんな感じでどうでしょうか？

実行結果

Validation Application Block で構成ファイルを利用した検証ルールの設定

tatsumihr(honekichi19@hotmail.com) — Sun, 05 Aug 2007 13:26:00 GMT

Enterprise Library 3.1 の Validation Application Block で、構成ファイルを利用した検証ルールの設定方法を記事にまとめました。

Validation Application Block を使おう！！　～構成ファイル編～

構成ファイルに検証ルールを設定する事で、Visual Studioで自動生成されたクラスのメソッドやプロパティについても、Designer.csを触ることなく検証できます。

今回はデータセットに対して検証をかけるというサンプルを作ってみました。実行結果はこんな感じです。

DataGridViewにバインドしたDataSetに対して検証をかけます。データベースからデータを取得してそれを編集し、データベースへ再登録する、なんていう処理を行うときに、データベース再登録前に値チェックを行うと思います。そんなときにもValidation Application Blockを利用することがきます。

結構簡単にできるのでお試しあれ！！

App.config、Web.configに設定した別の構成ファイルを読み込む

tatsumihr(honekichi19@hotmail.com) — Sat, 14 Jul 2007 21:41:00 GMT

アプリケーション構成ファイル（App.config）にカスタム構成セクションを追加するでは、構成ファイルにカスタム構成セクションを追加する方法を解説しました。

今回はそれを応用して、App.configに別の構成ファイルのパスを指定し、その構成ファイルを読み込む方法を解説します。アプリケーションが大規模になればなるほど、1つの構成ファイルに全ての設定を行うことは現実的ではありません。構成ファイルを複数に分割して、それぞれを必要に応じて読み込むことが必要になります。そんなときのヒントになれば良いなと思います。

記事の方に書いたので、興味のある方は以下のリンクからどうぞ～

アプリケーション構成ファイル（App.config）に設定した別の構成ファイルを読み込む

Validation Application Block を使おう！！　～属性編～

tatsumihr(honekichi19@hotmail.com) — Sat, 23 Jun 2007 11:25:00 GMT

EnterpriseLibrary3.1がリリースして早1ヶ月。巷で話題(？)のValidation Application Blockを使ってみました。今まで入力値検証の実装にかなり苦労していただけに、期待も高いApplication Blockです。ちょっと触ってみましたが、なかなか使い勝手も良さそうです！

ということで、触ってみた感想も踏まえてご紹介。今回は属性を使って入力値検証を行う方法です。設定ファイルを使った検証ルールの指定の仕方、ValidationProviderの使い方、Validation Application Blockの中身の解説などは、機会を見て追々やろうかなと。

=== 属性を使った入力値検証 ===

まずは完成系です。それぞれのテキストボックスに値を入れてValidateボタンを押下します。すると入力値検証エラーになった項目に対して、ValidationResultツリービューにエラーメッセージを表示するという、とても簡単なサンプルです。

Validation Application Blockについて書き出したら長くなったので、詳細は「記事」の方に譲ります。画像のような入力値検証を結構簡単に作る事ができますよ！！要チェックのApplication Blockです。

詳しくはこちら→　Validation Application Block を使おう！！　～属性編～