2

struts2 には、基本的に検証を導入する 2 つの方法があります。

  • プログラムで、または
  • 宣言的に。

プログラムによる検証では、基本的にValidatableアクション クラスにインターフェイスを実装する必要があり、そのためにメソッドを具体化void validate();する必要があります。検証の問題がユーザーに報告される場合、より複雑なインターフェースが存在しますValidationAware。

宣言型検証では、検証する各アクションmyactionname-validation.xmlは、XML 記述言語を使用してバリデーターが宣言されている、呼び出される独自の検証ファイルを取得します。

私が働いている会社では、プログラムによる検証の原則を使用しており、小規模な検証フレームワーク (社内で作成) を使用して、一般的な検証パターンを再利用しています。私はstruts2の本を読んだばかりですが、宣言的な検証が推奨される方法です。この本は、宣言型検証のセットアップ方法について多くの指示を与えていますが、宣言型の方法が望ましい理由についてはほとんど触れていません。

宣言型の XML スタイルの構成を支持する一般的な議論がいくつか見られますが、実際にはそれらがここに適用されるとは思えません。この構成の変更 (つまり、検証) は、処理されるモデルと密接に結びついているものです。モデルの値を変更するために使用されるアクションと GUI によって。これは、再コンパイルせずに「オンザフライ」で構成可能にする必要があるものではありません。

struts2 で宣言型の検証を使用するには、どのような引数がありますか?

さらに別の XML マークアップ方言に飛び込んで、個別の validation.xml ファイルの処理に煩わされる価値はありますか? プログラムで実行する方が簡単ではないでしょうか。また、Java ソース コード (または選択した IDE) がリファクタリング ツールや構造化検索などを提供してくれるので、さらにメンテナンスしやすいのではないでしょうか。

4

2 に答える 2

1

宣言型検証は、より読みやすく、非常に強力で、カスタマイズ可能です。また、適切に記述されたWebアプリケーション（適切なDTOまたはVO定義、実行する論理アクションごとに1つのアクション）では、さまざまな方法で共有できます。

たとえば、Visitorバリデーター（JSPからオブジェクトのリストを検証するため）を使用する場合、.xmlファイルをアクションパッケージではなくオブジェクトパッケージ（オブジェクト名を含む）に配置し、そのオブジェクトを複数で使用する場合アクションでは、検証ルールを1回記述し、必要な回数だけ再利用します。

私はXML構成のファンではありませんが、古い方法でいくつかのプロジェクトを行った後、この種の検証の可能性を完全に発見したので、戻ってきませんでした。

あなたが知りたいかもしれないいくつかのヒントについてはこれを見てください。

于 2012-11-02T13:18:48.343 に答える
0

プログラムで行う方が簡単ではないでしょうか [...]

それほど難しくはありませんが、そうではありません。エラー メッセージの作成はより手作業のプロセスですが、ほとんどの人は XML で実行できる機能を十分に活用していません。

[...]おそらくより保守しやすい[...]

それほど難しくはありませんが、そうではありません。

コード gen IMO を使用するコード ベースの場合、XML を構築する方が Java を構築するよりも簡単ですが、ほとんどのコード ベースはその深さでコード gen を使用しません。

人間が読めるドキュメントを作成する場合、XML と注釈は Java コードよりもはるかに簡単に処理できます。

私はかなりまともな S2 サポートを備えた IDE を使用しています。「これをコードで書いていれば、もっと簡単だったのに」と思ったことは一度もありません。 XML ではなくコードであってほしいと思った私の検証。

ポイントは、存在する場合は既存のメカニズムを再利用することです。これは、フレームワークに統合された簡単な既知のメカニズムであり、S2 アプリで作業している誰もがそのしくみを知っています。

于 2012-11-02T11:08:48.943 に答える