入力の有効化箇所

ビジネス層がWebによって消費され、ビジネス層の機能の一部がREST Webサービスとして公開されているとします。入力の有効化箇所

プレゼンテーションレイヤー（WebまたはREST Webサービス）またはビジネスレイヤーでビジネスロジックの入力検証を行い、プレゼンテーションレイヤーで検証エラー（ビジネスレイヤーによって投げられる）をキャプチャしますか？

出典

2011-01-09 mete

疑いで、

あなたが扱っすることができるので、ビジネス層にビジネスロジック（税込入力検証ロジックを）置くことが一般的に優れている（具体的に春のフレームワークが使用されています）あなたは、コードを繰り返し、そのロジックの2つのインスタンス

グーを管理したくない複数のプレゼンテーション媒体（例えば、ウェブGUIとAPI）

dフレームワークを使用すると、そのようなロジックを共通の場所に定義して、早い段階で（例えば、プレゼンテーション層で）、より直感的な（早いフェイル）、よりスケーラブルな（フロントエンドが）

ただし、フレームワークでこの機能がサポートされていない場合は、整合性と保守性を優先して、ロジックをビジネスレイヤに配置する必要があります。

出典

2011-01-09 20:50:41 kvista

これらのKellyを指摘してくれてありがとう。私はこれらに同意するが、問題は、私は、ビジネスレイヤーで無効な入力を拒否するかもしれないと思うが、プレゼンテーションレイヤーでは、より細かい検証エラーが必要な場合がある（フィールドaとフィールドbを別々に）。これを行うには、できるだけ細かいバリデーションをすべてビジネスレイヤーに入れ、プレゼンテーションレイヤーに応じて動作させる必要がありますか？私は春のことを考えています。私が明確な解決策を見つけたのかどうかはわかりません。私は春には新しいので、ポイントがありません。いかなる説明も歓迎されます。 – mete

すべてのレイターで検証を実装することをおすすめします。私はユーザーエクスペリエンスが高く、即時のフィードバックが得られるようにUIを行います。しかし、私はUIによって提供されるデータを信頼することはありません（JSを無効にするユーザーと考える）。サーバー側の検証の詳細は、あなた次第です。しかし、可能ならば、ユーザーはサーバーへの完全な往復旅行に苦しむ必要がなくなります。

出典

2011-01-09 20:51:30

+1 "UIによって提供されたデータを信用しない"。 –

ビジネスルールの違反は、常にビジネス層で発生します。プロアクティブなチェックを許可するかどうかは、ラウンドトリップを避けるためにクライアントで熱心にチェックしたいかどうかのように、設計上の決定です。

出典

2011-01-09 20:51:55 Paul

答えて

関連する問題