3

私は MVC に比較的慣れておらず、MVC 4 ベースの Web アプリケーションのフレームワークをまとめようとしています。

この質問は私の質問と似ていますが、コミュニティに評価してもらいたい特定の状況があります。

MVC 4 Web アプリケーションと Windows サービスの 2 つのコンポーネントを持つソフトウェア システムがあります。「モデル」レイヤー (ドメイン テーブルなどを指しています) は、Windows サービスと Web アプリケーションの両方からアクセスされます。

近い将来、かなりの量の機能をモバイル アプリに公開する計画もあり、API もモデルを使用します。

機能の重複は、Web アプリケーションと API (モバイル アプリ) の場合です。

私の場合に固有のいくつかの質問を次に示します。

  1. ビュー モデルを Web アプリケーションと API で同じ機能 (Web とモバイル アプリで公開されている個人のアドレスの更新など) で再利用することは良い考えですか? 検証 (例: 住所の検証 - 住所行、市区町村、都道府県、郵便番号をすべて組み合わせたもの) はどこに置くべきですか?
  2. Windows サービスの機能は、本質的に Web+API をより補完します (リマインダー メールを送信する夜間ジョブなど) が、Web+API で使用される「モデル」部分と重複する可能性があります。サービスが「モデル」を直接使用するか、「ViewModel」のようなレイヤーを使用することをお勧めします。この場合、検証はどこに行きますか？
  3. より多くの情報が必要なもう 1 つの概念的な質問は、属性駆動型の検証が MVC フレームワークによって実装されていることです。つまり、ビュー モデルを取得し、ビュー モデル プロパティの検証属性を見つけて、関連する検証を挿入するのは MVC アーキテクチャです。 . API の場合、およびモデルが Windows サービスによって消費される場合、この属性主導の検証はどのように機能しますか?
4

2 に答える 2

2

検証 (モデルまたはビューモデル) を配置するのに最適な場所は?

エラー検証への最善のアプローチの代用質問です。そして、それは宗教的な議論を開始する可能性があります. 興味深いことに、別の場所は選択肢ではないと思いましたか?

長所と短所、または考慮すべきポイントのリストは、開始するのに適した場所です。ただし、適切な選択は、目の前のタスクのサイズと複雑さによって異なります。たとえば、任意のチャネル (webUI/Windows UI/ WCF API など) からすべてのエラー検証を再利用できるようにしたい。「ルール」を一元的に宣言し、それらをどこにでも表示して翻訳したい。エラー チェックのアプローチとして、データベースの制約を回避したい。ただし、データ アクセス レイヤーの検証もアプローチの一部であり、例外を処理する方法です。EG 同時実行。ご覧のとおり、簡単な答えはありません。

考慮事項:

モデルの検証

  • 注釈、例えば [必須]、[StringLength(n)]
  • IValidatableObject を使用する
  • どちらも、MVC、Entity Framework などの他のフレームワークによってチェックまたはトリガーできます。
  • オブジェクトを直接参照し、DDD に適合するチェック。オブジェクトは、その基本的なビジネス ルールを知っている必要があります。たとえば、フィールド X の場合、Y は ....
  • しかし、論理的な重複のチェックなど、クロスオブジェクトチェックを簡単に行うことはできません。
  • チェックを行うために他のデータを「読み取る」必要がある場合は、レイヤーの分離とコントロールの反転が課題になります。
  • クロス オブジェクト チェックはモデルにうまく適合せず、実際には独自のレイヤー/レベルが必要です

モデルチェックを見る

  • インターフェイスから注釈を継承する方法。ビューモデルの注釈で「ルール」の重複を避ける方法。

  • クライアント側対サーバー側の検証へのアプローチは、いくつかの設計を促進します。クライアント側の検証手法の選択もインポートされます。MVC 注釈、データ、カスタム JavaScript フレームワーク?

  • ビュー モデルの一部のルールは、個々のオブジェクトではなくプロセスに適用されます。このロジックは ViewModel にあるべきですか? またはビジネスプロセスレイヤー？

個人的には、コアアウトのアプローチがベストだと思います。モデルでできるだけ多くのルールを直接宣言します。ただし、ビジネスプロセス層のルールもあります。ビジネス プロセス/サービス レイヤーを使用して、ビジネス レベルのクロス オブジェクト チェックを行います。継承するか、可能であれば重複せずに中央のルールを引き出します。単純な注釈を超えるには、ビルドにさらに労力が必要です。例 [必須] ビュー モデルで簡単に実行できます。それを維持することは難しくありませんが、モデルとビューモデルの組み合わせの数によっては面倒です。ただし、Json/Ajax を中心点からドラッグされたカスタム ビルドのルールで使用することは、モデルに複雑な JavaScript といくつかの「メタ」データ アプローチを含む別のオプションです。

そしてもちろん、使いやすさのためにクライアント側の検証を使用してください。

于 2013-06-02T14:03:13.890 に答える
0

免責事項: 正しい答えが何であるかはわかりませんが、とにかくコメントします (受け入れることを期待していません)。また、この回答は1、2、または3には対応していません。

私の現在のプロジェクトでは、ビュー モデルとデータベース側で検証を使用しています。ビュー モデルの検証は、ユーザーが無効なビュー モデルを投稿したときにそのフィードバックを提供するために目立たない ajax と共に使用できるため、ビュー モデルの検証はユーザーにフィードバックを提供できます。

データベースの前の検証は、データの正確性を確認するためのものであり、ビューモデルの検証とカスタム検証を大部分複製します。場合によっては、データベースの検証に追加のチェックがあり、無効なモデルがある場合は、エラーがビューに戻されます。それは非常に非効率的です。誰かがより良い解決策を提案してくれることを願っています。

追加情報: 役立つヒントをもう 1 つ紹介します。API または Windows サービスからのオブジェクトでビューモデル検証を使用することは、それらが同じプロパティを持っている場合に可能です。「ASP.net 以外のコンテキストで C# のデータ検証属性を使用するにはどうすればよいですか?」を参照してください。

于 2013-06-02T08:05:45.317 に答える