2015-07-10 68 views
2

我有一个关于在ServiceStack中使用FluentValidation的问题。ServiceStack - FluentValidation

例如:

[Route("/customers/{Id}", "PUT")] 
public class UpdateCustomer : IReturn<Customer> 
{ 
    public int Id { get; set; } 

    public string FirstName { get; set; } 
    public string LastName { get; set; } 
} 

[Route("/customers/{Id}", "DELETE")] 
public class DeleteCustomer : IReturnVoid 
{ 
    public int Id { get; set; } 
} 

public class Customer 
{ 
    public int Id { get; set; } 

    public string FirstName { get; set; } 
    public string LastName { get; set; } 
} 

当我更新客户信息,我想验证例如所有的参数,可以删除,但它例如当,我只是想确保ID是例如正INT。所以,名字,姓氏等一切我不在乎的情况下。

如果我的客户类实现FluentValidator,我将不得不把所有的逻辑验证内部对于(应用基于请求路径不同的规则)?或者有更优雅的方式来做到这一点?

回答

2

的验证只应在请求DTO的,如:

public class UpdateCustomerValidator : AbstractValidator<UpdateCustomer> 
{ 
    public UpdateCustomerValidator() 
    { 
     RuleFor(r => r.Id).GreaterThan(0); 
     RuleFor(r => r.FirstName).NotEmpty(); 
     RuleFor(r => r.LastName).NotEmpty(); 
    } 
} 

,同样也DeleteCustomer,如:

public class DeleteCustomerValidator : AbstractValidator<DeleteCustomer> 
{ 
    public DeleteCustomerValidator() 
    { 
     RuleFor(r => r.Id).GreaterThan(0); 
    } 
} 

虽然创造了单场整体验证可以矫枉过正如此您可以在您的服务中添加验证,例如:

public class CustomerServices : Service 
{ 
    public void Any(DeleteCustomer request) 
    { 
     if (request.Id <= 0) 
      throw new ArgumentException("Id Required", "Id") 

     Db.DeleteById<Customer>(request.Id); 
    } 
} 
+1

感谢您的回答,n我知道我的问题是多么愚蠢:) 顺便说一句,在上面的情况下,使用响应dto是一个大问题吗?我的意思是不遵循服务堆栈模式中的命名约定,例如** UpdateCustomerResponse **,** CreateCustomerResponse **,它也将矫枉过正,基本上重复了** Customer **响应dto。 – ShP

+0

@ShP使用特定响应的好处DTO能够在不破坏服务合同的情况下发展服务(即添加更多属性)(因此现有客户端继续工作)。它也是SOAP所必需的,否则你不需要它。 – mythz