5

サーバー側のDbContext検証エラーをクライアントに戻す方法がわかりません。Breeze には、 などのいくつかの属性に反応するデフォルトのバリデーターがあることは理解していますRequiredが、他のすべての属性についてはどうでしょうか? クライアント側でチェックする Breeze 用のカスタム JavaScript バリデータを作成することもできますが、エンティティがサーバー側で有効であることも確認する必要があります。

たとえば、アプリケーションPersonには有効な電子メール アドレスが必要です。EmailAddress悪意のあるユーザーがやって来て、クライアントを通過して電子メール アドレスを取得し、バリデータを通過しないデータをサーバーに投稿します。これまでのところ、Breeze での私の経験では、電子メール アドレスが保存され、DbContextEntity Framework エラーが発生することはありません。

以下のモデルを想定すると、エンティティ検証エラーを取得する最良の方法は何ですか?

public class PeopleContext : DbContext
{
    public PeopleContext()
        : base("name=ConnectionString"){ }

    public DbSet<Person> People { get; set; }
}

public class Person
{
    public int PersonId { get; set; }
    public string FirstName { get; set; }
    [Required]
    public string LastName { get; set; }
    [EmailAddress]
    [Required]
    public string Email { get; set; }
}

更新 1:

私が経験している問題を再現するための手順を次に示します。

  1. 指示に従って「Todo」サンプルを作成します ( http://www.breezejs.com/documentation/start-nuget )

  2. BreezeSampleTodoItem.cs新しいカスタム バリデータをファイルに追加します。

    [AttributeUsage(AttributeTargets.Property)]
public class CustomValidator : ValidationAttribute
{
    public override Boolean IsValid(Object value)
    {
        string val = (string)value;
        if (!string.IsNullOrEmpty(val) && val == "Error")
        {
            ErrorMessage = "{0} equal the word 'Error'";
            return false;
        }
        return true;
    }
}

  3. Descriptionフィールドを新しいカスタム バリデータで装飾します。

    [CustomValidator]
public string Description { get; set; }

  4. usingもちろん、適切な s (Systemおよび) を追加しますSystem.ComponentModel.DataAnnotations。

  5. プロジェクトを実行します。
  6. 説明フィールドの 1 つに「エラー」と入力して保存します。

DbEntityValidationExceptionこれは、Breeze を介してエラーが発生したり、Entity Framework からスローされることさえあると予想される場所です。2台の別々のコンピューターで試しましたが、同じ結果が得られました。エンティティは、エラーがなかったかのようにデータベースに保存されます。実際、IsValidカスタム バリデータのメソッド内の任意の場所にブレークポイントを配置すると、呼び出されていないことがわかります。

4

2 に答える 2

3

Breeze v 0.78.1以降、登録されているすべてのDbContextサーバー側の検証がEntityManagerSaveChanges呼び出し中に実行されるようになりました。例外が発生すると、保存がロールバックされ、検証エラーがシリアル化されてBreezeクライアントに戻されます。

この機能は、（DbContextではなく）古いObjectContextベースのEFモデルではまだサポートされていないことに注意してください。

そして...この問題を発見し、解決策を提案してくれたadamljに感謝します。

于 2012-12-16T08:42:33.207 に答える
1

私はあなたが何を意味するのか分かりません

サーバー側の DbContext 検証エラーをクライアントに返す

検証エラー メッセージをクライアントに送信することを意味する場合があります。しかし、質問の残りの部分は、(a) サーバーでカスタム検証を実行する方法と、(b) クライアントでその検証の対応する JavaScript バージョンを取得して実行する方法を知りたいことを示唆しています。あなたの質問のこの解釈に対処します。

サーバ

Entity Framework (例で使用している) は、データ注釈検証ルールを自動的に実行します...その機能を手動で無効にしない限り。適切な方法でカスタム検証規則を作成すると、EF はこれらも実行します。Daniel Wertheim によるこの投稿では、そのようなルールの書き方について説明しています。その投稿を詳細に保証することはできませんが、私には正しいようです。カスタムの Email-validation 属性も定義しています!

カスタムの Data Annotation 検証ルールを作成するのがバロックすぎると思われる場合 (私にはよくあることですが)、 「サーバー側インターセプトBeforeSave...」で説明されている方法の 1 つで独自の検証ロジックを記述して呼び出すことができます。

これらが最良のサーバーオプションだと思います。クライアントに...

クライアント

Breeze はクライアント側の JavaScript 検証を登録して、メタデータ内のネットワークを通過する特定のサーバー側のデータ注釈(Requiredおよび など) と一致させます。MaxLength私が書いているように、カスタムのデータ注釈は認識されず、メタデータに含まれず、クライアントにはすぐに使用できるアナログはありません。クライアントがこれらのルールを使用してエンティティを事前に選別するようにする場合は、対応する独自の JavaScript バリデータを作成し、検証ドキュメント ページで説明されているように、適切なエンティティ タイプに登録する必要があります。

提案やより良い代替案がある場合は、ぜひお聞かせください。

于 2012-12-13T07:35:38.137 に答える