LightSwitch : 組み込みのバリデーションとバリデーションルールのカスタマイズ

日時型(Date, DateTime)の組み込みバリデーションの記述を追加しました。(2011年10月16日)

LightSwitch のバリデーション(入力値の検証)について整理してみます。
※基本的な内容ですが一応まとめてみました。漏れがあったらご指摘ください。

  バリデーションの内容 バリデーションの方法
Null チェック 入力必須列で、値が入力されているかどうかを検証する 列のプロパティで [検証] カテゴリーの [必要である] をチェックする
最大文字列長 文字列の最大長を越えていないことを検証する String 型の列のプロパティで [検証] カテゴリーの [最大長] に長さを指定する
数値の範囲/上限・下限 数値型で最小値~最大値の範囲の値、または上限値以下、下限値以上の値が入力されているかどうかを検証する 数値型(Integer, Long Integer, Short Integer, Double) で [検証] カテゴリーの [最小値] および [最大値] に値を入力する
日時の範囲/上限・下限 日時型(Date, DateTime)で範囲、または期限外の価が入力されているかどうかを検証する 日付型(Date, DateTime)で [検証] カテゴリーの [最小値] および [最大値] に値を入力する
通貨型の精度および小数点以下 通貨型の精度(桁数)および小数点以下の桁数が指定のものであるかどうかを検証する
※数値型と同様に最小値・最大値も検証できる
Money 型で [検証] カテゴリーの [精度] および [小数点以下桁数] を指定する
組み込みのビジネス型書式 組み込みの “Phone Number” および “Email Address” で適切な書式の入力値であるかどうかを検証する “Phone Number”、“Email Address” 型を使用する(自動的にそれぞれの型の検証ができる)
カスタムバリデーション 上記のバリデーションでは不可能な検証を行う 検証を行いたい列で [検証] カテゴリーの [カスタム検証] をクリックして、バリデーションルールをコーディングする
エクステンション(LightSwitch の拡張機能) を使うバリデーション 複数箇所で同じカスタムバリデーションが必要な時にビジネス型のエクステンションを開発して、アプリケーションで利用することができる  

 

例として、以下のテーブルを作ってみます。
※無理矢理な列の組み合わせですみません。

image


Null チェック

列の定義で [必要である] をチェックすると、Null ではないことを検証できます。

SNAGHTMLf1600e

image


文字列の最大長チェック

String 型の列で [最大長] を指定すると、それ以上の長さの入力は不正になります。

SNAGHTMLf6ba7d

image

最小の長さは指定できないので、必要な場合は後述のカスタムバリデーションを使用する必要があります。


数値の範囲/上限・下限のチェック

数値型で、入力可能な範囲、または上限値・下限値を指定できます。
範囲が必要な場合は [最小値]、[最大値] とも指定します。どちらか一方の指定も可能。
なお LightSwitch の組み込みの数値型は、Integer, Long Integer, Short Integer, Double です。

image

image

 

日時型の範囲/上限/下限のチェック
Date 型および DateTime 型でも数値と同様に範囲と期限の上下限を指定できます。
日時で [最小値]、[最大値] という表現は少し馴染まない感じもありますが、言わんとしていることはわかりますね。
数値と同じように指定します。

※日時型のバリデーションについて追記しました。(2011年10月16日)

 


通貨型の精度および小数点以下の桁数チェック

通貨型(Money)は、精度および小数点以下の桁数を検証することができます。
精度とは、整数の桁数と小数点以下の桁数の合計(小数点は桁数に含まない)のことです。

image

image

数値型と同じように、最小値・最大値を指定することもできます。


組み込みのビジネス型書式

LightSwitch には組み込みのビジネス型として “Phone Number” および “Email Address” があります。
それぞれの型に適した書式であるかどうかをチェックすることができます。

“Phone Number ” では有効な形式を変更することができます。例えば、日本国内の電話番号しか使わない場合は国コードは不要なので、市外局番から始まる形式のみにすると、ユーザーが入力するのが楽になります。

image

image


カスタムバリデーション

組み込みのバリデーションでは実現できない場合は、カスタムバリデーションを定義できます。

例えば以下のような場合があります。

  • 開始日より終了日が後でなければならない
  • 受注日より配送日が後でなければならない
  • 文字列長の最短の指定が必要
  • 複数フィールドの少なくとも1つに有効な値が入力されていない蹴ればならない
  • 有効な値が複雑なルールで決定する
  • などなど・・・

複数フィールドの関係で有効・無効が決まる場合はカスタムバリデーションを使う必要があります。他には複雑なルールの場合もカスタムバリデーションで実現しなければなりません。

image

image

image

バリデーションに失敗させるには results.AddPropertyError メソッドでエラーメッセージを指定します。
成功の場合はそのままバリデーション用のメソッドを抜けるだけです(LightSwitch のフレームワークは PropertyError が空ならばバリデーション成功と見なします)。


エクステンションを使うバリデーション

カスタムバリデーションを使えば複雑なバリデーションが可能ですが、同様の検証を複数箇所で使いたい場合、あるいは社内的に複数アプリケーションで共用する可能性のあるバリデーションはエクステンション(LightSwitch の拡張機能)を開発して実現することができます。

LightSwitch のエクステンションには6種類ありますが、バリデーションのためには ビジネス型エクステンション (BusinessType Extension) を使います。
LightSwitch のエクステンション開発については改めて投稿します。
(難しいのよね・・・)

広告
カテゴリー: LightSwitch タグ: パーマリンク

LightSwitch : 組み込みのバリデーションとバリデーションルールのカスタマイズ への7件のフィードバック

  1. とこほ より:

    組み込みデータ型には、GUID型っというのもありますよ。

  2. seosoft より:

    コメントありがとうございます。(Wordpressがスパム扱いしていたので気づくのが遅くなりました・・・)

    すみません、GUIDの組み込みバリデーションを見つけられないのですが (>_<)、どういうルールになってるか、ぜひご教示ください。あとはどこでバリデーションの指定することができますか?
    プロパティウィンドウだとカスタムのバリデーションしか選択できないように見えますが、何を見落としてるのかわかってないのです。

  3. とこほ より:

    そぉですね。
    プロパティウィンドウだと「カスタム検証」しかできません...。

    いっかい配置して、テーブルをSQL Serverに吐き出して
    Guidのフィールドをみてみると…
    SQL Serverの既定値に(8桁-4桁-4桁-4桁-12桁)のGUID形式が指定されています。
    Guidなので今後かわる事もないので、これ(↑)でやってるのかな???

  4. seosoft より:

    すみません、やっぱりGUIDのバリデーションが見つけられません。どうやったらバリデートするところにお目にかかれるのかわかってないです orz

    ただ、おかげで(?)、Date と DateTime のバリデーションの記述を漏らしているのに気づきました。Min/Max のバリデーションがありますね。というより、勉強不足で Date, DateTime のバリデーションはノーマークでした。
    まずは、そこを追記しておきます。助かりました。

  5. とこほ より:

    あら?
    バリデーション=入力検証ですよね?
    PhoneNumberみたいに、書式が正しいかチェックされる機能のことですよね?

    Guidフィールド作って、「必要」にすると
    新規データ画面で初期値がセットされてて、
    不正値に変えると「変換エラー」がポップアップされませんか?

    Guidフィールド作って、「必要」のチェックを外しとくと
    新規データ画面で初期値は空白になるので
    不正値を入力すると「変換エラー」がポップアップされませんか?

    (変換エラーのメッセージ例)
    入力した値(‘z’)は無効なため、前の値に戻されました。
    変換エラー:GUIDには、ハイフンを4つ含む32桁の数字
    (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)を含んでいなければなりません。

    私の勘違いでしたらすみません...

  6. seosoft より:

    おっしゃっている意味がわかりました。物わかり悪くてすみません。

    GUIDはバリデーションは行われていないと思いますよ。
    あれは論理的な型チェックだと思います。int に “Hello, World” を入れられないのと一緒です。

    書き方を工夫すればよかったんですが、バリデーションは意味的な入力値チェックということだと理解していただければ。
    つまり、例えば40文字の文字列は言語的な観点では正しいけれど、アプリケーションの仕様で32文字までという制限がついていれば不正な値ということになります。これを防ぐのがバリデーションですね。

    あとは職業プログラマーじゃない人も LightSwitch でアプリを開発することはあると思うので、そういう人のためには確かに啓蒙は必要だと思いますが、そもそも GUID を人間に触らせることは開発者はしないわけですし、NewGuid した値を入れる以外の使い方はしないはずです。GUID にバリデーションは不要だと思いますし、バリデーションがないことは個人的には特に不思議には思いません。

  7. とこほ より:

    失礼いたしました。
    瀬尾さんは「組み込みのバリデーション」のお話しをしているのに
    私の最初のコメントは「組み込みデータ型」の話でした…。
    私のWebサイト記事が利用可能な「データ型」→それぞれの「データ検証」っという切り口だったので (^^;;;

    それっとバリデーションの意味も、ちょっと誤解しておりました。
    解説していただき ありがとうございました。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中