将业务逻辑排除在控制器之外是常识。使用存储库模式，数据库访问逻辑应该在存储库上也是常识，如下所述：存储库模式
但是，存储库模式只指定了非常简单的低级数据库操作：插入、删除、更新、选择。人们也建议不要使用验证逻辑。这不是问题，因为大多数验证都可以放在模型对象本身中。当我们需要进行某种交叉验证时，问题就出现了，即需要查看同一模型对象的多个实例的验证（例如，确保名称在同一对象的所有实例中是唯一的) 或者，更糟糕的是，当验证逻辑需要检查两个或多个不同类型的对象时。在这种情况下，我们有一个真正的大漏洞：业务逻辑不能在控制器中，不能在存储库中，不能在对象模型本身中（因为逻辑不仅仅绑定到对象的属性）。这个逻辑应该在哪里？这种需求的最佳设计模式是什么？
You can create a service layer as described here: http://www.asp.net/mvc/tutorials/older-versions/models-(data)/validating-with-a-service-layer-cs
这里的问题是您的设计需要 UI 根据业务问题进行验证。
实现这一点的方法是将验证抽象到业务层中。您的业务层可能有类似的方法ValidateUserIsUnique()，然后您的 ui 调用该层并接收结果，然后将其用于验证。
特别是，对于客户端验证，MVC 提供了RemoteValidationAttribute，但这只会进行客户端验证。您还需要执行在服务器上调用相同（或类似）函数的服务器端验证。