あまり知られていない，Webアプリ開発時の１０の略語 （例文つき）

バリデーション系

• サーバリ　（サーバサイド・バリデーション）

• クラバリ　（クライアントサイド・バリデーション）

• モデバリ　（モデルクラスによるバリデーション）

• コンバリ　（コントローラクラスによるバリデーション）

• デーバリ　（DB上の制約によるバリデーション）

メソッド分類系

• モデメソ　（モデルクラス内のメソッド）

• コンメソ　（コントローラクラス内のメソッド）

• ヘルメソ　（ヘルパーモジュール内のメソッド）

その他系

• ワントラ　（１個のトランザクション）

• コマプロ　（コマンドプロンプト。またはコマンドプロンプトのプロフェッショナル）

以下解説。Webアプリのアーキテクチャの話も含む。

バリデーション系

• クラバリ（クライアントサイド・バリデーション）：
  • ブラウザ上で，JavaScriptなどを使って，submit前に入力値の異常を検出するバリデーション方式。

• サーバリ（サーバサイド・バリデーション）：
  • Webサーバ上で，submitされたHTTPリクエストを解析し，リクエストの異常を検出するバリデーション方式。

例文：

クラバリだけでは，インターネット公開時のセキュリティに穴がある。

かといってサーバリだけでは，ブラウザ上でのユーザビリティが悪い。

だから，サーバリもクラバリも必要だ。

バリデーションロジックの実装箇所を重複させないよう，工夫して設計しよう。

このアプリはイントラネット限定だし，機能もごく限られているので，クラバリだけで済ましましょう。

重複チェックを実装する件ですが，画面上での重複じゃなくて，

DB内での重複をチェックするんですよね。

そうするといったんサーバ側にsubmitが必要になるんで，クラバリじゃ無理なんです。

陰でサーバリさせる分には構わないんで，Ajaxで問い合わせさせますか？

参考：

クライアントサーバシステム　と　web系システム　の違い
http://oshiete.goo.ne.jp/qa/2569501.html

クライアントサーバシステムとWeb系のシステムの違い
http://www.atmarkit.co.jp/bbs/phpBB/v...

サーバリは，以下の３つに分類される。

• コンバリ（コントローラクラスによるバリデーション）：
  • コントローラクラスによるバリデーション。画面遷移やセッションなど，通信に関わる妥当性を担保する。

• モデバリ（モデルクラスによるバリデーション）：
  • モデルクラスによるバリデーション実装。アプリケーション上でのデータモデルの妥当性を担保する。

• デーバリ（DB上の制約によるバリデーション）：
  • DB上の制約によるバリデーション。NOT NULL制約など。DB上に実際に格納される値の妥当性を担保する。
  • ※インドに「デーヴァナガリー文字」という名前の文字が存在する。この略語はその名前を彷彿させる。

例文：

Ruby on RailsのActive Recordには，モデバリ用のメソッドがたくさん用意されている。

例えば，validates_numericality_of( カラム名 ) というメソッドを使うと，

該当カラムに登録される予定の値が有効な数値かどうか，バリデーションできる。

StrutsのValidatorプラグイン利用時には，まずstruts-config.xml内でFormクラスを指定し，

次いでvalidation.xml内で，そのFormに対して検証ルールを記述する。

このアーキテクチャでは，永続化レイヤ（エンティティ）ではなくフォームが検証対象なので，

ユーザ入力値はコンバリされていると言える。

もし違和感を感じた場合は，Hibernate Validatorを使って，検証対象の概念を変えてしまおう。

そうすればモデバリと呼べる。

Railsでは，config/routes.rb 内にルーティング情報を書く。

この中にrequirements属性を含めることにより，URLに変な引数が入ってこないようにはじく事ができる。

このアーキテクチャでは，サーバ境界の外側の情報をバリデーションしているので，

これはサーバリの中でもコンバリの一種であると言える。

ここでは，運用担当者がCUIでDB更新したりするんだ。

だから，ストアドプロシージャでデーバリを作り込んどかないと，運用ミスに対処できないよ。

Aさん「DBのカラムの『型』って，バリデーションの一種なのかな？

　型があれば，変な値が登録されないようにはじけるよね。

　例えばINTEGERなら，数値以外の値が入らないようにブロックできるけど。」

Bさん「いい質問だね。

　データの状態には，正常と異常の２パターンがある。

　現在の状態が正常なのか異常なのかを判定する『行為』がバリデーションだ。

　それに対し型というのは，そもそも異常な状態を許さないよね。

　型は，その名の通り，物理的で静的な『入れ物』のようなものなんだ。
　　
　一方バリデーションはより論理的で，知能的で，動的な『活動』と呼べるかもしれない。」

Aさん「へ〜。確かに，共通点と相違点があるね。

　じゃあ，DBのカラムに VARCHAR(255) という型を割り当てたら，

　そもそも255を超える文字は入らないわけだから，

　この型というもの自体は，デーバリではないわけだね。」

Bさん「そう言えると思うよ。逆に，もしTEXT型のカラムがあるとして，

　レコードINSERT時のトリガでストアドを呼び出して，

　そのカラムに登録しようとしている値が255文字以内かチェックする，

　という検証行為を実装した場合，それはデーバリと呼べるだろうね。」

Aさん「同じ考え方で，HTMLのinput要素にmaxlength属性を付与して，

　入力値を制限した場合も，それはクラバリではなく，

　一種の『型』に近いという事になるのかな。」

Bさん「その場合，静的制約と動的制約のうちでは前者に分類されるからね。

　確かに制約ではあるんだけど，クラバリではないと思うよ。」

参考：

インドの文字分布：デーヴァナガリ文字
http://www.aa.tufs.ac.jp/i-moji/tenji...

Strutsで作るセキュアWebアプリケーション Validatorを利用した入力値チェックの注意点
http://www.atmarkit.co.jp/fsecurity/r...

Hibernate Validatorを使う
http://www.grandnature.net/blog/archi...

• エンティティクラスにアノテーションで制約を記述する。
• 検証ルールに反する値をセットしてsave()すると例外を投げる。

なお「コンバリ」と「モデバリ」は，一般的にも区別されている存在だ。

書籍「J2EEパターン」で，プレゼンテーション層の設計項目として「バリデーション」を扱った見出しがある。
（第１版ならセクション3.1.3）

その中では，Webシステムのバリデーションは，下記のような分類になっている：

• クライアント側でのバリデーション（＝クラバリ）

• サーバ側でのバリデーション（＝サーバリ）
  • フォームベースのバリデーション（＝コンバリ）：重複が増加しやすい。フォームが増えたらその分だけ，モデルの性質を記述する箇所も増えてしまうから。
  • 抽象型ベースのバリデーション（＝モデバリ）：結合度が低く汎用的になる。モデルの状態とAPのロジックを分離できるため。

注：

J2EEパターンの初版公開は2001年4月。直前のJDKバージョンは1.3（2000年5月）
http://www.exa-corp.co.jp/techinfo/re...
http://ja.wikipedia.org/wiki/Java#.E3...

書籍「J2EEパターン―明暗を分ける設計の戦略」の初版の発売は2002年7月，２版は2005年5月
http://www.amazon.co.jp/dp/4894714345/
http://www.amazon.co.jp/dp/4822282287/

なんだけども，それらは邦訳の出版日であり，原著「Core J2EE Patterns」の第２版の出版日は2003年6月。
なので，J2SE5.0（2004年9月）でJavaが別言語になってしまうよりも前に書かれた本。
http://www.amazon.co.jp/dp/0131422464/

第2版ではActive Recordパターンが追加され，Ruby on Railsに影響を与えた
http://thinkit.co.jp/article/941/1?pa...

メソッド分類系

• モデメソ（モデルクラス内のメソッド）：
  • モデルクラス内のメソッド。テーブル単位でのCRUD操作や，ビジネスロジックを記述する。

• コンメソ（コントローラクラス内のメソッド）：
  • コントローラクラス内のメソッド。モデルとビューの仲介役を果たす。
  • 「コンソメ」という言葉に似ている。

• ヘルメソ（ヘルパーモジュール内のメソッド）：
  • ヘルパーモジュール内のメソッド。ビューを描画するためのロジックを記述する。
  • 平仮名で「へるめそ」と書くと，なんだかかわいい。

※なお，Strutsのtaglibはヘルパーの一種である。View-Helperパターンを知らないでtaglibを使っている場合は，一度J2EEパターンを学んでおくこと。

例文：

Cookieの処理，共通のコンメソに切り出しておきますね。

ヘルメソは，ビューを書くためのDSLだ。

そうすれば，ビューのソースコードファイルは，そのまま画面設計書として利用できる。

モデメソとヘルメソの役割分担を混同しないように気をつけましょう。

データ構造に関わる処理は，モデメソに記述します。

見せ方に関わる処理は，ヘルメソに記述します。

例えば，DBの特定のカラム内に，カンマ区切りで複数の数値が格納されているとします。

そして，これらの数値をブラウザ上でリスト形式で表示したいとします。

この時のモデメソの役目は，カラムの中身をカンマでsplitし，

配列という「扱いやすいデータ構造」で返すことだけです。

一方，ヘルメソの役目は，配列を受け取り，

配列の各要素に対してHTMLのli要素を付加し，結合して文字列として返すことです。

モデメソとヘルメソの間の部分で持ちまわっているデータが，

文字列ではなく配列のような「加工しやすい抽象的なデータ構造」

である点に注意してください。

なお，モデメソの吐いたデータを，ヘルメソの書いてあるビューにまで届けるのは

仲介役であるコンメソの役割です。

参考：

Ruby on RailsのModel内に記述するメソッドの分類表
http://language-and-engineering.hatenablog.jp/entry/20100901/p1

その他

• ワントラ（１個のトランザクション）：
  • 業務上ひとかたまりとみなすデータ処理行為。外部設計時に，画面や機能を分割する際の基準になる。
  • 「ワン」も「トラ」も動物を連想させる。

• コマプロ（コマンドプロンプト。またはコマンドプロンプトのプロ）：
  • Webアプリケーションに限定せず，開発時に何かとお世話になるWindowsのシェル。または，それを使いこなせる人のこと。
  • 「パワプロ」のような略し方。語尾が「プロ」で終わるので，コマンドプロンプトを指すのか，それともそれを使いこなす人のことを指すのかが不明という罠がある。

例文：

機能定義書から処理の単位がわかるので，そこでわかったワントラごとに，

それぞれ入力画面と完了画面を設計していきましょう。

コマプロを使いこなせるようになったら，あなたをコマプロと呼んであげよう。

参考：

誰も教えてくれない用語集　コマプロ
http://wiki.livedoor.jp/nobo_i0902/d/...

これらの略語を使ってよい状況

使ってよい状況

• 日常会話

• ミーティング

• SVNコミット時のログ

• ソースコードのコメント（ただしxDocの利用状況による）

• 仕様メモ　など

• 特に，張り詰めた空気の状況で，かわいい略語を意識的に使うことによって雰囲気を和らげること

使ってはいけない状況

• 納品するドキュメント

• オフィシャルな会議　など