.NET Developer Empire

帝国の逆襲

ホーム 連絡をする 同期する ( RSS 2.0 ) Login
投稿数  14  : 記事  5  : コメント  44  : トラックバック  8

記事カテゴリ

書庫

2008年7月15日 #

●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を使うのがいいのかな?とも思いますが。

posted @ 8:06 | Feedback (0)

2007年9月27日 #

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

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

さて困った。。。

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

posted @ 9:23 | Feedback (12)

2007年8月11日 #

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だと、コネクション作るのに時間かかるから、毎回完全にリリースしてしまうと効率が悪そう。個人的に大体こんな結論になりました。

posted @ 10:03 | Feedback (3)

2007年8月7日 #

Close

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

Dispose

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

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

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

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

posted @ 22:35 | Feedback (7)

2007年8月5日 #

先ほど書いた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を自由に作る事もできます。

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

実行結果

posted @ 20:08 | Feedback (2)

SELECT @@IDENTITY

これです!!

SQL Serverってあまりいじってなかったんだけど、最近どうしても必要になったので、手探りながら触ってます。

主キーの自動採番を使おうとIDENTITYを指定したんだけど、どうやってレコード挿入後にIDENTITY列を取得しようかと調べていたら見つけたもの。

SQL文の最後に「SELECT  @@IDENTITY」をつけるだけで良いって、楽すぎるじゃないか!!

ちょっと幸せになれた瞬間でしたー

なにかもっと幸せになれることないかなぁ???


正解は「SCOPE_IDENTITY」でした!! (2007/8/6)

以下、MSDNでの解説URL。

http://msdn2.microsoft.com/ja-JP/library/ms190315.aspx

http://msdn2.microsoft.com/ja-JP/library/ms187342.aspx


むらぷろさんがこの件についてまとめてくれました。以下のブログです。

SQL Server によるIDの生成

posted @ 15:27 | Feedback (6)

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

Validation Application Block を使おう!! ~構成ファイル編~

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

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

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

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

posted @ 13:26 | Feedback (0)

2007年7月14日 #

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

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

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

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

 

posted @ 21:41 | Feedback (0)

2007年6月23日 #

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

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

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

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

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

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

posted @ 11:25 | Feedback (2)

2007年6月20日 #

MSDNマガジンに「ADO.NET Entity Framework」についての記事がありました。

データ ポイント: ADO.NET Entity Framework の概要

最近は.NET Framework 3.0が出たと思ってたら、もう.NET Framework 3.5ですか。。。何だか技術の進歩が早すぎて追いつけない現状です。何をどう使うのが良いのか検証している時間がないなぁ。

とりあえず技術検証が必要な項目。

  • EnterpriseLibrary3.1
  • WPF
  • WF
  • ASP.NET AJAX
  • LINQ
  • Entity SQL
  • バンカーショット
  • 変化球

うん、プライベートでもやることがいっぱいだー orz...

posted @ 20:37 | Feedback (0)