用户输入验证和业务对象验证混淆答案

【问题标题】：User input validation and business object validation confusion用户输入验证和业务对象验证混淆
【发布时间】：2011-06-09 01:13:05
【问题描述】：

我正试图集中精力验证用户输入和验证业务对象。假设我正在使用 Customer 对象。它具有以下属性：CustomerId、FirstName 和 LastName。 FirstName 和 LastName 为必填项，长度不能超过 50 个字符。

我正在使用 ASP.NET MVC 3。我也在试验 Fluent Validation（但不必是这个验证框架）。

当我在 Create customer 视图中时，我将一个 CustomerViewModel 传递给该视图：

[Validator(typeof(CustomerViewModelValidator))]
public class CustomerViewModel
{
   public string FirstName { get; set; }
   public string LastName { get; set; }
}

在 CustomerViewModelValidator 中，我如上所述设置了验证所需的规则。这一切都在视图上验证得很好。现在我有一个问题。在我的应用程序中，我有一个服务层，在这里我想应用所有应用程序逻辑。假设我想保存一个新客户，那么我将在 CustomerService 中有一个 Save customer 方法，它调用 CustomerRepository 的 Save 方法。

我可能有另一个应用程序（上述 Web 应用程序除外）将使用我的服务层。所以这意味着如果创建了一个客户对象，我将不得不验证一个客户对象。出现以下问题：

是否还需要验证 CustomerService 中的 Customer 对象以检查 FirstName 和 LastName？
创建一个新的验证器类来验证 Customer 类会更好吗？还是我应该分享它？
我还需要验证 CustomerId 吗？我的意思是它应该大于零，但是我将如何验证 ID 为 0 的新客户？

如果有人能分享一些对此的见解/文章将不胜感激。

我也想添加一些业务规则，这会在哪里？我在哪里以及如何实施业务规则？

【问题讨论】：

标签： asp.net-mvc validation architecture business-rules fluentvalidation

【解决方案1】：

我是否还需要验证 CustomerService 中的 Customer 对象以检查 FirstName 和 LastName？

在这个问题上可能有不同的意见，我的观点是，如果您正在创建一个可重用的服务，那么在服务级别验证 Customer 对象会更正确。

创建一个新的验证器类来验证 Customer 类会更好吗？还是我应该分享？

您应该创建一个新的验证器。请记住CustomerViewModel 和Customer 是两个不同的类。视图模型特定于给定视图，并且可能包含模型类属性的子集或超集。服务层的验证应该只验证业务规则。如果您使用 SQL Server，甚至可以在数据库级别执行此验证（通过设置列的长度），如果其中一些业务规则是违反了。

【讨论】：