0

APIを構築し、コントローラーアクションにパラメーターとして渡された入力オブジェクトを検証する必要があります。同じ入力クラスが、アクションごとに異なる強制プロパティを持つ場合があります。

それで

public class test
{
public ActionResult Create(User user)
{
  //here user_name must be present but no user_id
}
public ActionResult Delete(User user)
{
  //here only user_id must be present.
}
}

私はfluentValidation.netを見てきましたが、クラス/アクションではなく、クラスごとにルールを作成する必要があるようです。

ありがとう。

4

1 に答える 1

2

とはUser?

クラスがどこで定義されているかという意味ではなく、ドメイン内で物理的に何を意味するのかという意味です。複数のことを意味するようにしようとしているようです。

これらのアクションをドメインのモデルに当てはめようとする代わりに、それらのアクション モデルを作成します。このようなもの：

class CreateUserAction
{
  public string Username {get; set;}
}

class DeleteUserAction
{
  public int ID {get; set;}
}

次に、これらをアクション メソッドで使用します。

public ActionResult Create(CreateUserAction user)
{
}

public ActionResult Delete(DeleteUserAction user)
{
}

これにより、単一責任の原則に従って、さまざまな目的がさまざまなクラスに分類されます。クラスは、まだ作成されていないユーザーを表す場合や、ユーザー オブジェクトの ID のみを表す場合Userなどとは対照的に、単にユーザー オブジェクトを表すことに集中できるようになりました。

ここでの大きな利点の 1 つは、検証規則をクラスで直接指定できることです。このアプローチでは、Userオブジェクトは常にaUsername とanIDが有効である必要があります。一方、CreateUserActionオブジェクトには がなくID(必要がないため)、DeleteUserActionオブジェクトには がUsernameありません (必要がないため)。

必要に応じてさらにフィールドを追加できます。たとえば、CreateUserActionオブジェクトには、作成されるユーザーを説明する他のフィールドが含まれる可能性があります。(Userオブジェクトにはまったく含まれないが、ドメイン内の他のオブジェクトに変換されるフィールドがある場合もあります。) ただし、 はDeleteUserAction(IDそして、SLaks によって示唆されているように、おそらくintそのアクションメソッドだけに置き換えられますが、それはあなた次第です)。

クラスの役割と責任が明確になり、部分的に初期化された半オブジェクトが少なくなります。

于 2012-01-30T17:52:30.370 に答える