我一直在为GetRuleViolations()课程开发一种User方法，但是我对某些内容感到有些不知所措：
当不同的操作需要不同的业务规则时会发生什么？
我的User表格包含以下列：Id，UserRoleId，Username和Password。可能涉及User的几个操作（创建新用户，编辑用户，设置/重置密码和登录），并且每个操作的业务规则并不总是相同。
例如，当用户登录时，他们需要输入密码，但是当管理员创建新用户时，输入密码甚至不是一个选项。在设置/重置密码的情况下，需要输入密码两次，并且这两个值必须完全匹配。处理这种复杂性的最佳方法是什么？是否有某种设计模式允许在正确的情况下选择正确的GetRulesViolations()方法？
答案 0 :(得分：0)
对于＃1，业务规则将不存在于您的数据库中，它们将存在于应用程序中，无论是在域层，单独的业务层等中......还是在控制器中，具体取决于您的方法
您将向正在创建用户的登录管理员提供与创建帐户的未经身份验证的用户不同的屏幕或视图，对吗？来自该视图的HTTP-POST将对应于不同的操作，该操作将直接处理逻辑，或委托给适当的对象。一种方法将检查提供的密码，并为用户创建记录或将用户重定向到某种类型的故障页面（例如，“密码不匹配”或“已用户名”）。另一种方法是在数据库中创建一个新用户，没有问题。
发布到不同操作的不同视图，对应于不同的方法，每个方法处理一个特定的作业/场景。
答案 1 :(得分：0)
我发现处理验证的“服务层”很有意义。
我发现本教程非常有用： http://www.asp.net/learn/mvc/tutorial-38-cs.aspx
此外，看起来好像验证的一些很好的增强功能正在为MVC 2.0工作（参见http://weblogs.asp.net/scottgu/archive/2010/01/15/asp-net-mvc-2-model-validation.aspx）。使用UserService或UserValidator应该允许折叠2.0功能，而无需过多地更改类设计。