クライアント側の検証やモデル バインディングに関する回答には興味がありません。実際、この質問は MVC 以外のデータ アクセス クラス ライブラリにも当てはまりますが、問題は似ていると思います。
現在、エンティティ (モデル) でのデータ アクセスにリポジトリ パターンを使用しています。現在、リポジトリはすべての CRUD 操作を処理していますが、検証を行うためにモデルが自分自身を保存する責任があると思います。これをどのように処理すればよいですか？
リポジトリがモデルを保存する前にすべてのビジネス ロジックを実行できる IsValid メソッドをモデルに追加できますが、リポジトリがこの検証ロジックを呼び出すことを強制するものはありません。
モデルに Save メソッドを持たせたい場合、モデルが自分自身を保存する適切な方法は何ですか? リポジトリにコールバックするべきではありませんか?
これをどのように処理すべきかについて何か考えはありますか?
ありがとう！
モデルが保存操作を検証できるようにすることに本質的に問題はありません。falseを返したり、例外をスローしたりすることも可能です。入力したデータが無効である理由についてユーザーにフィードバックを提供する必要がある場合、問題が発生します。
検証は、最初にビューで実行でき、実行する必要があります。これは、jQueryライブラリを使用してクライアント側で簡単に実行できます。ただし、ユーザーが送信した後もデータをサーバー側で検証する必要があります。それでもデータに問題がある場合は、ユーザーに説明を提供する必要があります。
ユーザーフィードバックを提供する必要があるため、この種のサーバー側の検証は、ビューモデルオブジェクトで効果的に提供できます。このデータオブジェクトには2つの目的があります。1つは、ビューとコントローラーの間を通過するデータを厳密に型指定されたオブジェクトにカプセル化することです。次に、コントローラーまたはビューのいずれにも検証ロジックを必要とせずに、検証を実行するための便利な場所を提供します。
Linq to SQLを使用する場合、C＃でpartialキーワードを使用して、ビューモデルを実際のデータモデルクラスの拡張にすることができます。これにより、追加の検証機能に取り組みながら、生成されたLinqtoSQLクラスの既存のORM機能を使用できます。これは、EntityFrameworkや他のORMでも同じように機能すると思います。
モデルの表示については、NerdDinnerチュートリアルのhttp://nerddinnerbook.s3.amazonaws.com/Part6.htmで説明されています。
検証プロセスはここで説明されています：http：
//nerddinnerbook.s3.amazonaws.com/Part3.htm