Question

当我参与asp.net mvc网站项目时，我研究了不同的验证方法。其中一些是DataAnotation验证和验证块。他们使用属性来设置验证规则。像这样：

[Required]
public string Name {get;set;}

我很困惑这种方法如何与OOP世界的SRP（单一责任原则）相结合。另外我不喜欢业务对象中的任何业务逻辑，我更喜欢“糟糕的业务对象”模型，但是当我用实际需求的验证属性装饰我的业务对象时，它们变得丑陋（具有很多属性/具有本地化逻辑和等等）。

带有属性的想法很简单，但在我看来，验证装饰应该与对象分开。我不确定将验证规则分离到xml文件或其他对象的方法，也许这是一个解决方案。

AOP的另一个不好的方面 - 单元测试此类代码的问题。当我使用自定义属性修饰某些控制器操作时，例如在操作之间导入/导出TempData或初始化某些必需的服务，我无法编写适当的单元测试来测试此操作。

你认为属性不会破坏srp，或者你只是忽视这一点并认为它是最简单的，不是最差的方式吗？

P.S。我读了一些喜欢的文章和讨论，我只想把事情按顺序排列。

P.P.S。对不起我的“流利”英语：=）

修改我认为“破坏规则”和丑陋将在这种情况下：如果验证有一些业务规则 - 例如用户必须在系统中有唯一的电子邮件，您应该验证用户输入在应用程序中抛出所有层，因此当您编写自定义属性以检查此数据时，业务对象将与你的数据层抛出属性。

Answer 1

AOP本身不会破坏任何SOLID规则，尤其是SRP。

如果您在业务对象中使用UI验证属性，那么它肯定会破坏SRP。但是如果你在特殊的UI类中使用这些属性，这些属性是UI和BL之间的接口，那么一切都满足SRP。

Answer 2

我认为验证规则与您用于UI的模型对象有关。事实上，他们使用一组约束来描述您的每个数据，这些约束定义该数据的值是否可接受。

我也一直在努力解决这个问题，但我相信装修方法很好，因为你设置它并忘记它：如果你有外部验证，那么你有可能忘记应用验证，并最终数据无效。

我曾经使用过验证的getter和setter，这是一个可怕的想法。

有一种简单的方法可以将问题分成不同的地方：使用部分类。像往常一样定义您的类，但将其设置为partial，然后使用单独的文件来定义字段及其装饰：它们将合并到类中，而不会在代码中乱扔太多细节。