単体入力エラーチェックの実装パターン

さて Part 1. のエントリでは、業務処理の終了パターンの分類と、各アプリケーションタイプにおける基本的な実装パターンを整理しました。要点をまとめると、以下のようになります。 業務処理の終了パターンは、以下のように分類される。 突き合わせエラーについては、バックエンドのモジュール(BC や DAC)との連携によるチェック作業が必要になる。UI 部単体でチェックが可能なのは、単体入力エラーに限られる。 .NET Framework では、UI 開発技術として、ASP.NET, Silverlight, WPF, Windows フォームなど、様々なテクノロジが提供されています。これらの技術には、いずれにも、UI 部において、単体入力エラーチェックを効率よく実装していくための機能が備わっています。(これらの機能は、いずれも単体入力チェックを効率よく実装するための機能であり、突き合わせエラーのチェックや、システムエラーに関する対処を実装するための機能ではありません。いや無理矢理使えば使えるかもしれませんが;、それはこれらの機能が用意された目的や意図とはズレた使い方だと考えるべきだと思います。) ① ASP.NET Web フォーム : 入力検証コントロール ② Silverlight 3, WPF 3 : 例外ベースの双方向データバインド ③ Windows フォーム 2.0, WPF 3.5 : IDataErrorInfo ベースの双方向データバインド さてこれらの機能は、いずれも「単体入力チェックを行う」「フィールド単位のチェックとインスタンス単位のチェックを行う」という点においては違いがありません。しかし、その実装方法や、エラーチェックに対する考え方は、全くといっていいほど違います。この実装方法の特性の違いを理解しておかないと、単体入力エラーチェックをうまく実装できないばかりか、開発生産性をかえって大幅に損なう結果に繋がりかねません。特に、ASP.NET Web アプリケーション開発の入力検証コントロールの使い方に慣れた人が、Windows フォームや WPF などのテクノロジを遣うと、おそらく入力検証のやり方が全くといっていいほど違うため、相当に戸惑うことになるはずです。(というよりも私はむちゃくちゃ戸惑いましたよ....orz) 本エントリの目的は、これらの各テクノロジにおける、実装パターンの違い(実装方法やエラーチェックに対する考え方の違い)を明確化することです。 ① ASP.NET Web フォーム : 入力検証コントロール 検証コントロールを使って、「正しい文字列」を作成する方式 ②…

6

エラーチェックの体系的な分類方法

まず最初のエントリでは、「エラーチェック」とひとくくりにされている「エラー」を、体系的に分類することを試みてみます。このエントリでは、Web / Windows、あるいは Java / .NET などといった技術論とは無関係な部分についての解説を進めていきたいと思います。 エラーチェック(ユーザ入力検証)の意味 正常終了/業務エラー/システムエラーの分類 業務エラーの細分化 アーキテクチャから見たエラーチェックの実装場所 ※ なお、本エントリで解説されている分類方法や命名方法は、あくまで nakama 個人の考え方・整理方法です。もしかしたらもっとよい設計パターンなどがあるかもしれませんので、その辺についてはあしからずご了承ください;。 [エラーチェック(ユーザ入力検証)の意味] まずは、そもそもどのようなケースでエラーチェックが必要になるのか、ユーザ入力検証にどのような目的があるのかを考えてみましょう。 一般的に、業務アプリケーションは、参照系アプリケーションと更新系アプリケーションに大別されます。 参照系と更新系では、求められるアプリケーションの機能が大きく異なりますが、更新系アプリケーションでは、適切な入力エラーチェックをどのように実装するのかが、極めて重要なポイントになります。そもそもなぜ更新系アプリケーションでは、適切な入力エラーチェックが重要になるのか? ユーザ入力検証(エラーチェック)には、大別して以下の 2 つの目的があります。 アプリケーションの保護 ユーザから入力された値をそのまま利用すると、エラーやセキュリティ脆弱性の原因になってしまうため、適切にフォーマットチェックなどを行う必要があります。(SQL 挿入、Cross-Site Scripting など) ユーザビリティの向上 エンドユーザに親切なエラーメッセージを表示するように作成すると、使いやすいアプリケーションを実現することができます。 しかし、このようなユーザ入力検証機能(エラーチェック機能)を場当たり的に実装すると、開発生産性を大きく損なうことになります。このため、通常のアプリケーション開発では、ランタイムが持っている「ユーザ入力検証のための機能」をうまく活用して実装していくことが重要になるわけです。 こうしたランタイムのユーザ入力検証機能を利用する上で欠かせないのが、以下の 3 つのポイントに関する知識です。 アプリケーションの終了パターンの分類 正常終了/業務エラー/システムエラーを正しく分類できること。 業務エラーが、さらに単体入力エラーと突合せエラーに分類されることを知っていること。 アーキテクチャ的な観点から見た、エラーチェックの実装方法 論理 3 階層型アプリケーションにおいて、どこで何をチェックすべきかを判断できること。 ランタイムが持つバリデーション機能(エラーチェック機能)の狙い ランタイムが持つバリデーション機能のコンセプトの違いを理解していること。 どの部分をカバーする目的で作られているのか、どこまでできるのか、その限界点を理解していること。 本エントリでは、まずこのうち最初の、「エラーパターンの分類」の部分について解説します。 [正常終了/業務エラー/システムエラーの分類] 業務アプリケーションの「入力エラー」を考える上で欠かせないのが、ひとくくりに「エラー」とされているものを体系的に分類することです。これを考えるには、業務処理が終了するパターンを、以下の 3 つに分類するのが最初のスタートポイントになります。(※ この終了パターン分類は、nakama による勝手な分類で、業界標準でもなんでもありません;。あしからずご了承ください、とつぶやいてみる^^) 正常終了 : 特に問題なく、期待通りに業務処理が終了できた 業務エラー :…

0

エラーチェックの体系的な分類と実装パターン

というわけで久しくエントリをアップしていなかったこの blog ですが、最近、複数方面からお叱りの言葉が……; 忙しかったこともあってエントリをサボっていたこともあったのですが、ちょうどいいネタがなかったのも実際のところ。がしかし、先日 2009/9/26(土) に行った、わんくま同盟さんでの勉強会のネタが blog 化するにはちょうどいいだろう、という感じなので、その資料を使いつつ、blog エントリを書いてみることにします。 今回の解説ネタは、更新系業務アプリケーションで求められることになる、エラーチェックの実装パターンを体系的に分類してみる、というものです。ASP.NET や Windows フォームなどには様々なデータ入力検証のフレームワークがあるのですが、名称こそ同じ「データ入力検証」となっていても、データ入力検証に対する考え方は、フレームワークごとにかなり異なっています。そこで、本エントリでは、特に .NET Framework 標準のデータ入力検証機能である、以下の 3 つを横並びにして解説してみて、各データ入力検証にどのような食い違いがあるのかを解説してみたいと思います。 ASP.NET 検証コントロール Silverlight 3, WPF 3 の例外ベースの双方向データバインド Windows フォーム 2.0, WPF 3.5 の IDataErrorInfo ベースの双方向データバインド なお、今回のサンプルコードは以下になります。エントリ中では、キーポイントとなるコード部分についてしか触れませんので、詳細なコードについてはこちらのサンプルコードをご覧ください。 [Agenda] Part 1. エラーチェックの体系的な分類方法 エラーチェック(ユーザ入力検証)の意味 正常終了/業務エラー/システムエラーの分類 業務エラーの分類  アーキテクチャから見たエラーチェックの実装場所 Part 2. 単体入力エラーチェックの実装パターン ① ASP.NET Web フォームの場合 ② Silverlight 3, WPF 3 の場合…

0