「テスト」と「バリデーション」は，互いに酷似している。 単体テスト：開発者が，システムの入出力の振る舞いを検証すること。 バリデーション：システムが，ユーザの入力値を検証すること。 ユニットテストとバリデーションは本質的に同類の処理であり， その実装のために提供されるAPIも必然的に酷似するのである。*1 これら２つのコードは，工程やレイヤはまるっきり異なるが，まるで システムの同じ挙動を，２つの異なった角度・見地から見ている かのような，そっくりの類似性を持つことになる。 両者の違いは，下記のように要約される。 前者はシステム仕様を検証するためのテストケースであり，後者はシステム仕様そのものである。 検証操作を行なう主体と対象も異なる。（上図を参照） 本稿では，各種テストAPIや，各種バリデーションAPIのイディオムをさらっと概観する。 両者のAPIが確かに「共通の視点」を持っている事に
バリデーション系 サーバリ （サーバサイド・バリデーション） クラバリ （クライアントサイド・バリデーション） モデバリ （モデルクラスによるバリデーション） コンバリ （コントローラクラスによるバリデーション） デーバリ （DB上の制約によるバリデーション） メソッド分類系 モデメソ （モデルクラス内のメソッド） コンメソ （コントローラクラス内のメソッド） ヘルメソ （ヘルパーモジュール内のメソッド） その他系 ワントラ （１個のトランザクション） コマプロ （コマンドプロンプト。またはコマンドプロンプトのプロフェッショナル） 以下解説。Webアプリのアーキテクチャの話も含む。 バリデーション系 クラバリ（クライアントサイド・バリデーション）： ブラウザ上で，JavaScriptなどを使って，submit前に入力値の異常を検出するバリデーション方式。 サーバリ（サーバサイド・バリデーシ
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
codicは、プログラマーのためのネーミング辞書です。新しいcodicでは、翻訳エンジンを搭載しネーミングをジェネレートできるようになりました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く